Warning: Attempt to read property "date" on null in /usr/local/www/websvn.planix.org/blame.php on line 247

Warning: Attempt to read property "msg" on null in /usr/local/www/websvn.planix.org/blame.php on line 247
WebSVN – tendra.SVN – Blame – /branches/tendra4/doc/tcpplus/pragma.html – Rev 2

Subversion Repositories tendra.SVN

Rev

Go to most recent revision | Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
2 7u83 1 
<!-- Crown Copyright (c) 1998 -->
2 
<HTML>
3 
<HEAD>
4 
<TITLE>
5 
C++ Producer Guide: Configuration
6 
</TITLE>
7 
</HEAD>
8 
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
9 
 
10 
<H1>C++ Producer Guide</H1>
11 
<H3>March 1998</H3>
12 
<A HREF="token.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
13 
<A HREF="man.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
14 
<A HREF="index.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
15 
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
16 
</A>
17 
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
18 
<HR>
19 
 
20 
<DL>
21 
<DT><A HREF="#table"><B>2.2.1</B> - Portability tables</A><DD>
22 
<DT><A HREF="#low"><B>2.2.2</B> - Low level configuration</A><DD>
23 
<DT><A HREF="#scope"><B>2.2.3</B> - Checking scopes</A><DD>
24 
<DT><A HREF="#limits"><B>2.2.4</B> - Implementation limits</A><DD>
25 
<DT><A HREF="#lex"><B>2.2.5</B> - Lexical analysis</A><DD>
26 
<DT><A HREF="#keyword"><B>2.2.6</B> - Keywords</A><DD>
27 
<DT><A HREF="#comment"><B>2.2.7</B> - Comments</A><DD>
28 
<DT><A HREF="#identifier"><B>2.2.8</B> - Identifier names</A><DD>
29 
<DT><A HREF="#int"><B>2.2.9</B> - Integer literals</A><DD>
30 
<DT><A HREF="#char"><B>2.2.10</B> - Character literals and built-in
31 
types</A><DD>
32 
<DT><A HREF="#string"><B>2.2.11</B> - String literals</A><DD>
33 
<DT><A HREF="#escape"><B>2.2.12</B> - Escape sequences</A><DD>
34 
<DT><A HREF="#ppdir"><B>2.2.13</B> - Preprocessing directives</A><DD>
35 
<DT><A HREF="#target-if"><B>2.2.14</B> - Target dependent conditional
36 
inclusion</A><DD>
37 
<DT><A HREF="#include"><B>2.2.15</B> - File inclusion directives</A><DD>
38 
<DT><A HREF="#macro"><B>2.2.16</B> - Macro definitions</A><DD>
39 
<DT><A HREF="#empty"><B>2.2.17</B> - Empty source files</A><DD>
40 
<DT><A HREF="#std"><B>2.2.18</B> - The <CODE>std</CODE> namespace</A><DD>
41 
<DT><A HREF="#linkage"><B>2.2.19</B> - Object linkage</A><DD>
42 
<DT><A HREF="#static"><B>2.2.20</B> - Static identifiers</A><DD>
43 
<DT><A HREF="#decl_none"><B>2.2.21</B> - Empty declarations</A><DD>
44 
<DT><A HREF="#implicit"><B>2.2.22</B> - Implicit <CODE>int</CODE></A><DD>
45 
<DT><A HREF="#longlong"><B>2.2.23</B> - Extended integral types</A><DD>
46 
<DT><A HREF="#bitfield"><B>2.2.24</B> - Bitfield types</A><DD>
47 
<DT><A HREF="#elab"><B>2.2.25</B> - Elaborated type specifiers</A><DD>
48 
<DT><A HREF="#impl_func"><B>2.2.26</B> - Implicit function declarations</A><DD>
49 
<DT><A HREF="#weak"><B>2.2.27</B> - Weak function prototypes</A><DD>
50 
<DT><A HREF="#printf"><B>2.2.28</B> - <CODE>printf</CODE> and <CODE>scanf</CODE>
51 
argument checking</A><DD>
52 
<DT><A HREF="#typedef"><B>2.2.29</B> - Type declarations</A><DD>
53 
<DT><A HREF="#compatible"><B>2.2.30</B> - Type compatibility</A><DD>
54 
<DT><A HREF="#complete"><B>2.2.31</B> - Incomplete types</A><DD>
55 
<DT><A HREF="#conv"><B>2.2.32</B> - Type conversions</A><DD>
56 
<DT><A HREF="#cast"><B>2.2.33</B> - Cast expressions</A><DD>
57 
<DT><A HREF="#ellipsis"><B>2.2.34</B> - Ellipsis functions</A><DD>
58 
<DT><A HREF="#overload"><B>2.2.35</B> - Overloaded functions</A><DD>
59 
<DT><A HREF="#exp"><B>2.2.36</B> - Expressions</A><DD>
60 
<DT><A HREF="#init"><B>2.2.37</B> - Initialiser expressions</A><DD>
61 
<DT><A HREF="#lvalue"><B>2.2.38</B> - Lvalue expressions</A><DD>
62 
<DT><A HREF="#discard"><B>2.2.39</B> - Discarded expressions</A><DD>
63 
<DT><A HREF="#if"><B>2.2.40</B> - Conditional and iteration statements</A><DD>
64 
<DT><A HREF="#switch"><B>2.2.41</B> - Switch statements</A><DD>
65 
<DT><A HREF="#for"><B>2.2.42</B> - For statements</A><DD>
66 
<DT><A HREF="#return"><B>2.2.43</B> - Return statements</A><DD>
67 
<DT><A HREF="#reach"><B>2.2.44</B> - Unreached code analysis</A><DD>
68 
<DT><A HREF="#variable"><B>2.2.45</B> - Variable flow analysis</A><DD>
69 
<DT><A HREF="#hide"><B>2.2.46</B> - Variable hiding</A><DD>
70 
<DT><A HREF="#exception"><B>2.2.47</B> - Exception analysis</A><DD>
71 
<DT><A HREF="#template"><B>2.2.48</B> - Template compilation</A><DD>
72 
<DT><A HREF="#catch_all"><B>2.2.49</B> - Other checks</A><DD>
73 
</DL>
74 
<HR>
75 
 
76 
<H2>2.2. Compiler configuration</H2>
77 
<P>
78 
This section describes how the C++ producer can be configured to apply
79 
extra static checks or to support various dialects of C++.  In all
80 
cases the default behaviour is precisely that specified in the ISO
81 
C++ standard with no extra checks.
82 
</P>
83 
<P>
84 
Certain very basic configuration information is specified using a
85 
<A HREF="#table">portability table</A>, however the primary method
86 
of configuration is by means of <CODE>#pragma</CODE> directives.
87 
These directives may be placed within the program itself, however
88 
it is generally more convenient to group them into a
89 
<A HREF="man.html#start-up">start-up file</A> in order to create a
90 
<A NAME="usr">user-defined compilation profile</A>.  The
91 
<CODE>#pragma</CODE> directives recognised by the C++ producer have
92 
one of the equivalent forms:
93 
<PRE>
94 
	#pragma TenDRA ....
95 
	#pragma TenDRA++ ....
96 
</PRE>
97 
Some of these are common to the C and C++ producers (although often
98 
with differing default behaviour).  The C producer will ignore any
99 
<CODE>TenDRA++</CODE> directives, so these may be used in compilation
100 
profiles which are to be used by both producers.  In the descriptions
101 
below, the presence of a <CODE>++</CODE> is used to indicate a directive
102 
which is C++ specific; the other directives are common to both producers.
103 
</P>
104 
<P>
105 
Within the description of the <CODE>#pragma</CODE> syntax, <I>on</I>
106 
stands for <CODE>on</CODE>, <CODE>off</CODE> or <CODE>warning</CODE>,
107 
<I>allow</I> stands for <CODE>allow</CODE>, <CODE>disallow</CODE>
108 
or
109 
<CODE>warning</CODE>, <I>string-literal</I> is any string literal,
110 
<I>integer-literal</I> is any integer literal, <I>identifier</I> is
111 
any simple, unqualified identifier name, and <I>type-id</I> is any
112 
type identifier.  Other syntactic items are described in the text.
113 
A
114 
<A HREF="pragma1.html">complete grammar</A> for the <CODE>#pragma</CODE>
115 
directives accepted by the C++ producer is given as an annex.
116 
</P>
117 
 
118 
<HR>
119 
<H3><A NAME="table">2.2.1. Portability tables</A></H3>
120 
<P>
121 
Certain very basic configuration information is read from a file called
122 
a portability table, which may be specified to the producer using
123 
a
124 
<A HREF="man.html#table"><CODE>-n</CODE> option</A>.  This information
125 
includes the minimum sizes of the basic integral types, the
126 
<A HREF="#char">sign of plain <CODE>char</CODE></A>, and whether signed
127 
types can be assumed to be symmetric (for example, [-127,127]) or
128 
maximum (for example, [-128,127]).
129 
</P>
130 
<P>
131 
The default portability table values, which are built into the producer,
132 
can be expressed in the form:
133 
<PRE>
134 
	char_bits			8
135 
	short_bits			16
136 
	int_bits			16
137 
	long_bits			32
138 
	signed_range			symmetric
139 
	char_type			either
140 
	ptr_int				none
141 
	ptr_fn				no
142 
	non_prototype_checks		yes
143 
	multibyte			1
144 
</PRE>
145 
This illustrates the syntax for the portability table; note that all
146 
ten entries are required, even though the last four are ignored.
147 
</P>
148 
 
149 
<HR>
150 
<H3><A NAME="low">2.2.2. Low level configuration</A></H3>
151 
<P>
152 
The simplest level of configuration is to reset the severity level
153 
of a particular error message using:
154 
<PRE>
155 
	#pragma TenDRA++ error <I>string-literal on</I>
156 
	#pragma TenDRA++ error <I>string-literal allow</I>
157 
</PRE>
158 
The given <I>string-literal</I> should name an error from the
159 
<A HREF="error.html">error catalogue</A>.  A severity of <CODE>on</CODE>
160 
or <CODE>disallow</CODE> indicates that the associated diagnostic
161 
message should be an error, which causes the compilation to fail.
162 
A severity of
163 
<CODE>warning</CODE> indicates that the associated diagnostic message
164 
should be a warning, which is printed but allows the compilation to
165 
continue.  A severity of <CODE>off</CODE> or <CODE>allow</CODE>
166 
indicates that the associated error should be ignored.  Reducing the
167 
severity of any error from its default value, other than via one of
168 
the dialect directives described in this section, results in undefined
169 
behaviour.
170 
</P>
171 
<P>
172 
The next level of configuration is to reset the severity level of
173 
a particular compiler option using:
174 
<PRE>
175 
	#pragma TenDRA++ option <I>string-literal on</I>
176 
	#pragma TenDRA++ option <I>string-literal allow</I>
177 
</PRE>
178 
The given <I>string-literal</I> should name an option from the option
179 
catalogue.  The simplest form of compiler option just sets the severity
180 
level of one or more error messages.  Some of these options may require
181 
additional processing to be applied.
182 
<P>
183 
It is possible to link a particular error message to a particular
184 
compiler option using:
185 
<PRE>
186 
	#pragma TenDRA++ error <I>string-literal</I> as option <I>string-literal</I>
187 
</PRE>
188 
</P>
189 
<P>
190 
Note that the directive:
191 
<PRE>
192 
	#pragma TenDRA++ use error <I>string-literal</I>
193 
</PRE>
194 
can be used to raise a given error at any point in a translation unit
195 
in a similar fashion to the <CODE>#error</CODE> directive.  The values
196 
of any parameters for this error are unspecified.
197 
</P>
198 
<P>
199 
The directives just described give the primitive operations on error
200 
messages and compiler options.  Many of the remaining directives in
201 
this section are merely higher level ways of expressing these primitives.
202 
</P>
203 
 
204 
<HR>
205 
<H3><A NAME="scope">2.2.3. Checking scopes</A></H3>
206 
<P>
207 
Most compiler options are scoped.  A checking scope may be defined
208 
by enclosing a list of declarations within:
209 
<PRE>
210 
	#pragma TenDRA begin
211 
	....
212 
	#pragma TenDRA end
213 
</PRE>
214 
If the final <CODE>end</CODE> directive is omitted then the scope
215 
ends at the end of the translation unit.  Checking scopes may be nested
216 
in the obvious way.  A checking scope inherits its initial set of
217 
checks from its enclosing scope (this includes the implicit main checking
218 
scope consisting of the entire input file).  Any checks switched on
219 
or off within a scope apply only to the remainder of that scope and
220 
any scope it contains.  A particular check can only be set once in
221 
a given scope. The set of applied checks reverts to its previous state
222 
at the end of the scope.
223 
<P>
224 
A checking scope can be named using the directives:
225 
<PRE>
226 
	#pragma TenDRA begin name environment <I>identifier</I>
227 
	....
228 
	#pragma TenDRA end
229 
</PRE>
230 
Checking scope names occupy a namespace distinct from any other namespace
231 
within the translation unit.  A named scope defines a set of modifications
232 
to the current checking scope.  These modifications may be reapplied
233 
within a different scope using:
234 
<PRE>
235 
	#pragma TenDRA use environment <I>identifier</I>
236 
</PRE>
237 
The default behaviour is not to allow checks set in the named checking
238 
scope to be reset in the current scope.  This can however be modified
239 
using:
240 
<PRE>
241 
	#pragma TenDRA use environment <I>identifier</I> reset <I>allow</I>
242 
</PRE>
243 
</P>
244 
<P>
245 
Another use of a named checking scope is to associate a checking scope
246 
with a named include file directory.  This is done using:
247 
<PRE>
248 
	#pragma TenDRA directory <I>identifier</I> use environment <I>identifier</I>
249 
</PRE>
250 
where the directory name is one introduced via a
251 
<A HREF="man.html#directory"><CODE>-N</CODE> command-line option</A>.
252 
The effect of this directive, if a <CODE>#include</CODE> directive
253 
is found to resolve to a file from the given directory, is as if the
254 
file was enclosed in directives of the form:
255 
<PRE>
256 
	#pragma TenDRA begin
257 
	#pragma TenDRA use environment <I>identifier</I> reset allow
258 
	....
259 
	#pragma TenDRA end
260 
</PRE>
261 
</P>
262 
<P>
263 
The checks applied to the expansion of a macro definition are those
264 
from the scope in which the macro was defined, not that in which it
265 
was expanded. The macro arguments are checked in the scope in which
266 
they are specified, that is to say, the scope in which the macro is
267 
expanded.  This enables macro definitions to remain localised with
268 
respect to checking scopes.
269 
</P>
270 
 
271 
<HR>
272 
<H3><A NAME="limits">2.2.4. Implementation limits</A></H3>
273 
<P>
274 
This table gives the default implementation limits imposed by the
275 
C++ producer for the various implementation quantities listed in Annex
276 
B of the ISO C++ standard, together with the minimum limits allowed
277 
in ISO C and C++.  A default limit of <I>none</I> means that the quantity
278 
is limited only by the size of the host machine (either <CODE>ULONG_MAX</CODE>
279 
or until it runs out of memory).  A limit of <I>target</I> means that
280 
while no limits is imposed by the C++ front-end, particular target
281 
machines may impose such limits.
282 
</P>
283 
<CENTER>
284 
<TABLE BORDER>
285 
<TR><TH>Quantity identifier</TH>
286 
<TH>Min C limit</TH>  <TH>Min C++ limit</TH>
287 
<TH>Default limit</TH>
288 
<TR><TD ALIGN=CENTER>statement_depth</TD>
289 
<TD ALIGN=CENTER>15</TD>  <TD ALIGN=CENTER>256</TD>
290 
<TD ALIGN=CENTER>none</TD>
291 
<TR><TD ALIGN=CENTER>hash_if_depth</TD>
292 
<TD ALIGN=CENTER>8</TD>  <TD ALIGN=CENTER>256</TD>
293 
<TD ALIGN=CENTER>none</TD>
294 
<TR><TD ALIGN=CENTER>declarator_max</TD>
295 
<TD ALIGN=CENTER>12</TD>  <TD ALIGN=CENTER>256</TD>
296 
<TD ALIGN=CENTER>none</TD>
297 
<TR><TD ALIGN=CENTER>paren_depth</TD>
298 
<TD ALIGN=CENTER>32</TD>  <TD ALIGN=CENTER>256</TD>
299 
<TD ALIGN=CENTER>none</TD>
300 
<TR><TD ALIGN=CENTER>name_limit</TD>
301 
<TD ALIGN=CENTER>31</TD>  <TD ALIGN=CENTER>1024</TD>
302 
<TD ALIGN=CENTER>none</TD>
303 
<TR><TD ALIGN=CENTER>extern_name_limit</TD>
304 
<TD ALIGN=CENTER>6</TD>  <TD ALIGN=CENTER>1024</TD>
305 
<TD ALIGN=CENTER>target</TD>
306 
<TR><TD ALIGN=CENTER>external_ids</TD>
307 
<TD ALIGN=CENTER>511</TD>  <TD ALIGN=CENTER>65536</TD>
308 
<TD ALIGN=CENTER>target</TD>
309 
<TR><TD ALIGN=CENTER>block_ids</TD>
310 
<TD ALIGN=CENTER>127</TD>  <TD ALIGN=CENTER>1024</TD>
311 
<TD ALIGN=CENTER>none</TD>
312 
<TR><TD ALIGN=CENTER>macro_ids</TD>
313 
<TD ALIGN=CENTER>1024</TD>  <TD ALIGN=CENTER>65536</TD>
314 
<TD ALIGN=CENTER>none</TD>
315 
<TR><TD ALIGN=CENTER>func_pars</TD>
316 
<TD ALIGN=CENTER>31</TD>  <TD ALIGN=CENTER>256</TD>
317 
<TD ALIGN=CENTER>none</TD>
318 
<TR><TD ALIGN=CENTER>func_args</TD>
319 
<TD ALIGN=CENTER>31</TD>  <TD ALIGN=CENTER>256</TD>
320 
<TD ALIGN=CENTER>none</TD>
321 
<TR><TD ALIGN=CENTER>macro_pars</TD>
322 
<TD ALIGN=CENTER>31</TD>  <TD ALIGN=CENTER>256</TD>
323 
<TD ALIGN=CENTER>none</TD>
324 
<TR><TD ALIGN=CENTER>macro_args</TD>
325 
<TD ALIGN=CENTER>31</TD>  <TD ALIGN=CENTER>256</TD>
326 
<TD ALIGN=CENTER>none</TD>
327 
<TR><TD ALIGN=CENTER>line_length</TD>
328 
<TD ALIGN=CENTER>509</TD>  <TD ALIGN=CENTER>65536</TD>
329 
<TD ALIGN=CENTER>none</TD>
330 
<TR><TD ALIGN=CENTER>string_length</TD>
331 
<TD ALIGN=CENTER>509</TD>  <TD ALIGN=CENTER>65536</TD>
332 
<TD ALIGN=CENTER>none</TD>
333 
<TR><TD ALIGN=CENTER>sizeof_object</TD>
334 
<TD ALIGN=CENTER>32767</TD>  <TD ALIGN=CENTER>262144</TD>
335 
<TD ALIGN=CENTER>target</TD>
336 
<TR><TD ALIGN=CENTER>include_depth</TD>
337 
<TD ALIGN=CENTER>8</TD>  <TD ALIGN=CENTER>256</TD>
338 
<TD ALIGN=CENTER>256</TD>
339 
<TR><TD ALIGN=CENTER>switch_cases</TD>
340 
<TD ALIGN=CENTER>257</TD>  <TD ALIGN=CENTER>16384</TD>
341 
<TD ALIGN=CENTER>none</TD>
342 
<TR><TD ALIGN=CENTER>data_members</TD>
343 
<TD ALIGN=CENTER>127</TD>  <TD ALIGN=CENTER>16384</TD>
344 
<TD ALIGN=CENTER>none</TD>
345 
<TR><TD ALIGN=CENTER>enum_consts</TD>
346 
<TD ALIGN=CENTER>127</TD>  <TD ALIGN=CENTER>4096</TD>
347 
<TD ALIGN=CENTER>none</TD>
348 
<TR><TD ALIGN=CENTER>nested_class</TD>
349 
<TD ALIGN=CENTER>15</TD>  <TD ALIGN=CENTER>256</TD>
350 
<TD ALIGN=CENTER>none</TD>
351 
<TR><TD ALIGN=CENTER>atexit_funcs</TD>
352 
<TD ALIGN=CENTER>32</TD>  <TD ALIGN=CENTER>32</TD>
353 
<TD ALIGN=CENTER>target</TD>
354 
<TR><TD ALIGN=CENTER>base_classes</TD>
355 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>16384</TD>
356 
<TD ALIGN=CENTER>none</TD>
357 
<TR><TD ALIGN=CENTER>direct_bases</TD>
358 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>1024</TD>
359 
<TD ALIGN=CENTER>none</TD>
360 
<TR><TD ALIGN=CENTER>class_members</TD>
361 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>4096</TD>
362 
<TD ALIGN=CENTER>none</TD>
363 
<TR><TD ALIGN=CENTER>virtual_funcs</TD>
364 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>16384</TD>
365 
<TD ALIGN=CENTER>none</TD>
366 
<TR><TD ALIGN=CENTER>virtual_bases</TD>
367 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>1024</TD>
368 
<TD ALIGN=CENTER>none</TD>
369 
<TR><TD ALIGN=CENTER>static_members</TD>
370 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>1024</TD>
371 
<TD ALIGN=CENTER>none</TD>
372 
<TR><TD ALIGN=CENTER>friends</TD>
373 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>4096</TD>
374 
<TD ALIGN=CENTER>none</TD>
375 
<TR><TD ALIGN=CENTER>access_declarations</TD>
376 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>4096</TD>
377 
<TD ALIGN=CENTER>none</TD>
378 
<TR><TD ALIGN=CENTER>ctor_initializers</TD>
379 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>6144</TD>
380 
<TD ALIGN=CENTER>none</TD>
381 
<TR><TD ALIGN=CENTER>scope_qualifiers</TD>
382 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>256</TD>
383 
<TD ALIGN=CENTER>none</TD>
384 
<TR><TD ALIGN=CENTER>external_specs</TD>
385 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>1024</TD>
386 
<TD ALIGN=CENTER>none</TD>
387 
<TR><TD ALIGN=CENTER>template_pars</TD>
388 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>1024</TD>
389 
<TD ALIGN=CENTER>none</TD>
390 
<TR><TD ALIGN=CENTER>instance_depth</TD>
391 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>17</TD>
392 
<TD ALIGN=CENTER>17</TD>
393 
<TR><TD ALIGN=CENTER>exception_handlers</TD>
394 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>256</TD>
395 
<TD ALIGN=CENTER>none</TD>
396 
<TR><TD ALIGN=CENTER>exception_specs</TD>
397 
<TD ALIGN=CENTER>N/A</TD>  <TD ALIGN=CENTER>256</TD>
398 
<TD ALIGN=CENTER>none</TD>
399 
</TABLE>
400 
</CENTER>
401 
<P>
402 
It is possible to impose lower limits on most of the quantities listed
403 
above by means of the directive:
404 
<PRE>
405 
	#pragma TenDRA++ option value <I>string-literal integer-literal</I>
406 
</PRE>
407 
where <I>string-literal</I> gives one of the quantity identifiers
408 
listed above and <I>integer-literal</I> gives the limit to be imposed.
409 
An error is reported if the quantity exceeds this limit (note however
410 
that checks have not yet been implemented for all of the quantities
411 
listed).  Note that the <A HREF="#identifier"><CODE>name_limit</CODE></A>
412 
and
413 
<A HREF="#include"><CODE>include_depth</CODE></A> implementation limits
414 
can be set using dedicated directives.
415 
</P>
416 
<P>
417 
The maximum number of errors allowed before the producer bails out
418 
can be set using the directive:
419 
<PRE>
420 
	#pragma TenDRA++ set error limit <I>integer-literal</I>
421 
</PRE>
422 
The default value is 32.
423 
<P>
424 
 
425 
<HR>
426 
<H3><A NAME="lex">2.2.5. Lexical analysis</A></H3>
427 
<P>
428 
During lexical analysis, a source file which is not empty should end
429 
in a newline character.  It is possible to relax this constraint using
430 
the directive:
431 
<PRE>
432 
	#pragma TenDRA no nline after file end <I>allow</I>
433 
</PRE>
434 
</P>
435 
 
436 
<HR>
437 
<H3><A NAME="keyword">2.2.6. Keywords</A></H3>
438 
<P>
439 
In several places in this section it is described how to introduce
440 
keywords for TenDRA language extensions.  By default, no such extra
441 
keywords are defined.  There are also low-level directives for defining
442 
and undefining keywords.  The directive:
443 
<PRE>
444 
	#pragma TenDRA++ keyword <I>identifier</I> for keyword <I>identifier</I>
445 
</PRE>
446 
can be used to introduce a keyword (the first identifier) standing
447 
for the standard C++ keyword given by the second identifier.  The
448 
directive:
449 
<PRE>
450 
	#pragma TenDRA++ keyword <I>identifier</I> for operator <I>operator</I>
451 
</PRE>
452 
can similarly be used to introduce a keyword giving an alternative
453 
representation for the given operator or punctuator, as, for example,
454 
in:
455 
<PRE>
456 
	#pragma TenDRA++ keyword and for operator &amp;&amp;
457 
</PRE>
458 
Finally the directive:
459 
<PRE>
460 
	#pragma TenDRA++ undef keyword <I>identifier</I>
461 
</PRE>
462 
can be used to undefine a keyword.
463 
</P>
464 
 
465 
<HR>
466 
<H3><A NAME="comment">2.2.7. Comments</A></H3>
467 
<P>
468 
C-style comments do not nest.  The directive:
469 
<PRE>
470 
	#pragma TenDRA nested comment analysis <I>on</I>
471 
</PRE>
472 
enables a check for the characters <CODE>/*</CODE> within C-style
473 
comments.
474 
</P>
475 
 
476 
<HR>
477 
<H3><A NAME="identifier">2.2.8. Identifier names</A></H3>
478 
<P>
479 
During lexical analysis, each character in the source file has an
480 
associated look-up value which is used to determine whether the character
481 
can be used in an identifier name, is a white space character etc.
482 
These values are stored in a simple look-up table.  It is possible
483 
to set the look-up value using:
484 
<PRE>
485 
	#pragma TenDRA++ character <I>character-literal</I> as <I>character-literal</I> allow
486 
</PRE>
487 
which sets the look-up for the first character to be the default look-up
488 
for the second character.  The form:
489 
<PRE>
490 
	#pragma TenDRA++ character <I>character-literal</I> disallow
491 
</PRE>
492 
sets the look-up of the character to be that of an invalid character.
493 
The forms:
494 
<PRE>
495 
	#pragma TenDRA++ character <I>string-literal</I> as <I>character-literal</I> allow
496 
	#pragma TenDRA++ character <I>string-literal</I> disallow
497 
</PRE>
498 
can be used to modify the look-up values for the set of characters
499 
given by the string literal.  For example:
500 
<PRE>
501 
	#pragma TenDRA character '$' as 'a' allow
502 
	#pragma TenDRA character '\r' as ' ' allow
503 
</PRE>
504 
allows <CODE>$</CODE> to be used in identifier names (like <CODE>a</CODE>)
505 
and carriage return to be a white space character.  The former is
506 
a common dialect feature and can also be controlled by the directive:
507 
<PRE>
508 
	#pragma TenDRA dollar as ident <I>allow</I>
509 
</PRE>
510 
</P>
511 
<P>
512 
The maximum number of characters allowed in an identifier name can
513 
be set using the directives:
514 
<PRE>
515 
	#pragma TenDRA set name limit <I>integer-literal</I>
516 
	#pragma TenDRA++ set name limit <I>integer-literal</I> warning
517 
</PRE>
518 
This length is given by the <CODE>name_limit</CODE> implementation
519 
quantity
520 
<A HREF="#limits">mentioned above</A>.  Identifiers which exceed this
521 
length raise an error or a warning, but are not truncated.
522 
</P>
523 
 
524 
<HR>
525 
<H3><A NAME="int">2.2.9. Integer literals</A></H3>
526 
<P>
527 
The rules for finding the type of an integer literal can be described
528 
using directives of the form:
529 
<PRE>
530 
	#pragma TenDRA integer literal <I>literal-spec</I>
531 
</PRE>
532 
where:
533 
<PRE>
534 
	<I>literal-spec</I> :
535 
		<I>literal-base literal-suffix<SUB>opt</SUB> literal-type-list</I>
536 
 
537 
	<I>literal-base</I> :
538 
		octal
539 
		decimal
540 
		hexadecimal
541 
 
542 
	<I>literal-suffix</I> :
543 
		unsigned
544 
		long
545 
		unsigned long
546 
		long long
547 
		unsigned long long
548 
 
549 
	<I>literal-type-list</I> :
550 
		* <I>literal-type-spec</I>
551 
		<I>integer-literal literal-type-spec</I> | <I>literal-type-list</I>
552 
		? <I>literal-type-spec</I> | <I>literal-type-list</I>
553 
 
554 
	<I>literal-type-spec</I> :
555 
		: <I>type-id</I>
556 
		* <I>allow<SUB>opt</SUB></I> : <I>identifier</I>
557 
		* * <I>allow<SUB>opt</SUB></I> :
558 
</PRE>
559 
Each directive gives a literal base and suffix, describing the form
560 
of an integer literal, and a list of possible types for literals of
561 
this form. This list gives a mapping from the value of the literal
562 
to the type to be used to represent the literal.  There are three
563 
cases for the literal type; it may be a given integral type, it may
564 
be calculated using a given <A HREF="lib.html#literal">literal type
565 
token</A>, or it may cause an error to be raised.  There are also
566 
three cases for describing a literal range; it may be given by values
567 
less than or equal to a given integer literal, it may be given by
568 
values which are guaranteed to fit into a given integral type, or
569 
it may be match any value.  For example:
570 
<PRE>
571 
	#pragma token PROC ( VARIETY c ) VARIETY l_i # ~lit_int
572 
	#pragma TenDRA integer literal decimal 32767 : int | ** : l_i
573 
</PRE>
574 
describes how to find the type of a decimal literal with no suffix.
575 
Values less that or equal to 32767 have type <CODE>int</CODE>; larger
576 
values have target dependent type calculated using the token
577 
<CODE>~lit_int</CODE>.  Introducing a <CODE>warning</CODE> into the
578 
directive will cause a warning to be printed if the token is used
579 
to calculate the value.
580 
</P>
581 
<P>
582 
Note that this scheme extends that implemented by the C producer,
583 
because of the need for more accurate information in the C++ producer.
584 
For example, the specification above does not fully express the ISO
585 
rule that the type of a decimal integer is the first of the types
586 
<CODE>int</CODE>, <CODE>long</CODE> and <CODE>unsigned long</CODE>
587 
which it fits into (it only expresses the first step).  However with
588 
the C++ extensions it is possible to write:
589 
<PRE>
590 
	#pragma token PROC ( VARIETY c ) VARIETY l_i # ~lit_int
591 
	#pragma TenDRA integer literal decimal ? : int | ? : long |\
592 
	    ? : unsigned long | ** : l_i
593 
</PRE>
594 
</P>
595 
 
596 
<HR>
597 
<H3><A NAME="char">2.2.10. Character literals and built-in types</A></H3>
598 
<P>
599 
By default, a simple character literal has type <CODE>int</CODE> in
600 
C and type <CODE>char</CODE> in C++.  The type of such literals can
601 
be controlled using the directive:
602 
<PRE>
603 
	#pragma TenDRA++ set character literal : <I>type-id</I>
604 
</PRE>
605 
The type of a wide character literal is given by the implementation
606 
defined type <CODE>wchar_t</CODE>.  By default, the definition of
607 
this type is taken from the target machine's <CODE>&lt;stddef.h&gt;</CODE>
608 
C header (note that in ISO C++, <CODE>wchar_t</CODE> is actually a
609 
keyword, but its underlying representation must be the same as in
610 
C). This definition can be overridden in the producer by means of
611 
the directive:
612 
<PRE>
613 
	#pragma TenDRA set wchar_t : <I>type-id</I>
614 
</PRE>
615 
for an integral type <I>type-id</I>.  Similarly, the definitions of
616 
the other implementation dependent integral types which arise naturally
617 
within the language - the type of the difference of two pointers,
618 
<CODE>ptrdiff_t</CODE>, and the type of the <CODE>sizeof</CODE>
619 
operator, <CODE>size_t</CODE> - given in the <CODE>&lt;stddef.h&gt;</CODE>
620 
header can be overridden using the directives:
621 
<PRE>
622 
	#pragma TenDRA set ptrdiff_t : <I>type-id</I>
623 
	#pragma TenDRA set size_t : <I>type-id</I>
624 
</PRE>
625 
These directives are useful when targeting a specific machine on which
626 
the definitions of these types are known; while they may not affect
627 
the code generated they can cut down on spurious conversion warnings.
628 
Note that although these types are built into the producer they are
629 
not visible to the user unless an appropriate header is included (with
630 
the exception of the keyword <CODE>wchar_t</CODE> in ISO C++), however
631 
the directives:
632 
<PRE>
633 
	#pragma TenDRA++ type <I>identifier</I> for <I>type-name</I>
634 
</PRE>
635 
can be used to make these types visible.  They are equivalent to a
636 
<CODE>typedef</CODE> declaration of <I>identifier</I> as the given
637 
built-in type, <CODE>ptrdiff_t</CODE>, <CODE>size_t</CODE> or
638 
<CODE>wchar_t</CODE>.
639 
</P>
640 
<P>
641 
Whether plain <CODE>char</CODE> is signed or unsigned is implementation
642 
dependent.  By default the implementation is determined by the definition
643 
of the <A HREF="lib.html#arith"><CODE>~char</CODE> token</A>, however
644 
this can be overridden in the producer either by means of the
645 
<A HREF="#table">portability table</A> or by the directive:
646 
<PRE>
647 
	#pragma TenDRA character <I>character-sign</I>
648 
</PRE>
649 
where <I>character-sign</I> can be <CODE>signed</CODE>,
650 
<CODE>unsigned</CODE> or <CODE>either</CODE> (the default).  Again
651 
this directive is useful primarily when targeting a specific machine
652 
on which the signedness of <CODE>char</CODE> is known.
653 
</P>
654 
 
655 
<HR>
656 
<H3><A NAME="string">2.2.11. String literals</A></H3>
657 
<P>
658 
By default, character string literals have type <CODE>char [n]</CODE>
659 
in C and older dialects of C++, but type <CODE>const char [n]</CODE>
660 
in ISO C++.  Similarly wide string literals have type <CODE>wchar_t
661 
[n]</CODE>
662 
or <CODE>const wchar_t [n]</CODE>.  Whether string literals are
663 
<CODE>const</CODE> or not can be controlled using the two directives:
664 
<PRE>
665 
	#pragma TenDRA++ set string literal : const
666 
	#pragma TenDRA++ set string literal : no const
667 
</PRE>
668 
In the case where literals are <CODE>const</CODE>, the array-to-pointer
669 
conversion is allowed to cast away the <CODE>const</CODE> to allow
670 
for a degree of backwards compatibility.  The status of this deprecated
671 
conversion can be controlled using the directive:
672 
<PRE>
673 
	#pragma TenDRA writeable string literal <I>allow</I>
674 
</PRE>
675 
(yes, I know that that should be <CODE>writable</CODE>).  Note that
676 
this directive has a slightly different meaning in the C producer.
677 
</P>
678 
<P>
679 
Adjacent string literals tokens of similar types (either both character
680 
string literals or both wide string literals) are concatenated at
681 
an early stage in parser, however it is unspecified what happens if
682 
a character string literal token is adjacent to a wide string literal
683 
token.  By default this gives an error, but the directive:
684 
<PRE>
685 
	#pragma TenDRA unify incompatible string literal <I>allow</I>
686 
</PRE>
687 
can be used to enable the strings to be concatenated to give a wide
688 
string literal.
689 
</P>
690 
<P>
691 
If a <CODE>'</CODE> or <CODE>&quot;</CODE> character does not have
692 
a matching closing quote on the same line then it is undefined whether
693 
an implementation should report an unterminated string or treat the
694 
quote as a single unknown character.  By default, the C++ producer
695 
treats this as an unterminated string, but this behaviour can be controlled
696 
using the directive:
697 
<PRE>
698 
	#pragma TenDRA unmatched quote <I>allow</I>
699 
</PRE>
700 
</P>
701 
 
702 
<HR>
703 
<H3><A NAME="escape">2.2.12. Escape sequences</A></H3>
704 
<P>
705 
By default, if the character following the <CODE>\</CODE> in an escape
706 
sequence is not one of those listed in the ISO C or C++ standards
707 
then an error is given.  This behaviour, which is left unspecified
708 
by the standards, can be controlled by the directive:
709 
<PRE>
710 
	#pragma TenDRA unknown escape <I>allow</I>
711 
</PRE>
712 
The result is that the <CODE>\</CODE> in unknown escape sequences
713 
is ignored, so that <CODE>\z</CODE> is interpreted as <CODE>z</CODE>,
714 
for example.  Individual escape sequences can be enabled or disabled
715 
using the directives:
716 
<PRE>
717 
	#pragma TenDRA++ escape <I>character-literal</I> as <I>character-literal</I> allow
718 
	#pragma TenDRA++ escape <I>character-literal</I> disallow
719 
</PRE>
720 
so that, for example:
721 
<PRE>
722 
	#pragma TenDRA++ escape 'e' as '\033' allow
723 
	#pragma TenDRA++ escape 'a' disallow
724 
</PRE>
725 
sets <CODE>\e</CODE> to be the ASCII escape character and disables
726 
the alert character <CODE>\a</CODE>.
727 
</P>
728 
<P>
729 
By default, if the value of a character, given for example by a
730 
<CODE>\x</CODE> escape sequence, does not fit into its type then an
731 
error is given.  This implementation dependent behaviour can however
732 
be controlled by the directive:
733 
<PRE>
734 
	#pragma TenDRA character escape overflow <I>allow</I>
735 
</PRE>
736 
the value being converted to its type in the normal way.
737 
</P>
738 
 
739 
<HR>
740 
<H3><A NAME="ppdir">2.2.13. Preprocessing directives</A></H3>
741 
<P>
742 
Non-standard preprocessing directives can be controlled using the
743 
directives:
744 
<PRE>
745 
	#pragma TenDRA directive <I>ppdir allow</I>
746 
	#pragma TenDRA directive <I>ppdir</I> (ignore) <I>allow</I>
747 
</PRE>
748 
where <I>ppdir</I> can be <CODE>assert</CODE>, <CODE>file</CODE>,
749 
<CODE>ident</CODE>, <CODE>import</CODE> (C++ only),
750 
<CODE>include_next</CODE> (C++ only), <CODE>unassert</CODE>,
751 
<CODE>warning</CODE> (C++ only) or <CODE>weak</CODE>.  The second form
752 
causes the directive to be processed but ignored (note that there is no
753 
<CODE>(ignore) disallow</CODE> form).  The treatment of other unknown
754 
preprocessing directives can be controlled using:
755 
<PRE>
756 
	#pragma TenDRA unknown directive <I>allow</I>
757 
</PRE>
758 
Cases where the token following the <CODE>#</CODE> in a preprocessing
759 
directive is not an identifier can be controlled using:
760 
<PRE>
761 
	#pragma TenDRA no directive/nline after ident <I>allow</I>
762 
</PRE>
763 
When permitted, unknown preprocessing directives are ignored.
764 
</P>
765 
<P>
766 
By default, unknown <CODE>#pragma</CODE> directives are ignored without
767 
comment, however this behaviour can be modified using the directive:
768 
<PRE>
769 
	#pragma TenDRA unknown pragma <I>allow</I>
770 
</PRE>
771 
Note that any unknown <CODE>#pragma TenDRA</CODE> directives always
772 
give an error.
773 
</P>
774 
<P>
775 
Older preprocessors allowed text after <CODE>#else</CODE> and
776 
<CODE>#endif</CODE> directives.  The following directive can be used
777 
to enable such behaviour:
778 
<PRE>
779 
	#pragma TenDRA text after directive <I>allow</I>
780 
</PRE>
781 
Such text after a directive is ignored.
782 
</P>
783 
<P>
784 
Some older preprocessors have problems with white space in preprocessing
785 
directives - whether at the start of the line, before the initial
786 
<CODE>#</CODE>, or between the <CODE>#</CODE> and the directive identifier.
787 
Such white space can be detected using the directives:
788 
<PRE>
789 
	#pragma TenDRA indented # directive <I>allow</I>
790 
	#pragma TenDRA indented directive after # <I>allow</I>
791 
</PRE>
792 
respectively.
793 
</P>
794 
 
795 
<HR>
796 
<H3><A NAME="target-if">2.2.14. Target dependent conditional inclusion</A></H3>
797 
<P>
798 
One of the effects of trying to compile code in a target independent
799 
manner is that it is not always possible to completely evaluate the
800 
condition in a <CODE>#if</CODE> directive.  Thus the conditional inclusion
801 
needs to be preserved until the installer phase.  This can only be
802 
done if the target dependent <CODE>#if</CODE> is more structured than
803 
is normally required for preprocessing directives. There are two cases;
804 
in the first, where the <CODE>#if</CODE> appears in a statement, it
805 
is treated as if it were a <CODE>if</CODE> statement with braces including
806 
its branches; that is:
807 
<PRE>
808 
	#if cond
809 
	    true_statements
810 
	#else
811 
	    false_statements
812 
	#endif
813 
</PRE>
814 
maps to:
815 
<PRE>
816 
	if ( cond ) {
817 
	    true_statements
818 
	} else {
819 
	    false_statements
820 
	}
821 
</PRE>
822 
In the second case, where the <CODE>#if</CODE> appears in a list of
823 
declarations, normally gives an error.  The can however be overridden
824 
by the directive:
825 
<PRE>
826 
	#pragma TenDRA++ conditional declaration <I>allow</I>
827 
</PRE>
828 
which causes both branches of the <CODE>#if</CODE> to be analysed.
829 
</P>
830 
 
831 
<HR>
832 
<H3><A NAME="include">2.2.15. File inclusion directives</A></H3>
833 
<P>
834 
There is a maximum depth of nested <CODE>#include</CODE>
835 
directives allowed by the C++ producer. This depth is given by the
836 
<CODE>include_depth</CODE> implementation quantity
837 
<A HREF="#limits">mentioned above</A>.  Its value is fairly small
838 
in order to detect recursive inclusions.  The maximum depth can be
839 
set using:
840 
<PRE>
841 
	#pragma TenDRA includes depth <I>integer-literal</I>
842 
</PRE>
843 
</P>
844 
<P>
845 
A further check, for full pathnames in <CODE>#include</CODE> directives
846 
(which may not be portable), can be enabled using the directive:
847 
<PRE>
848 
	#pragma TenDRA++ complete file includes <I>allow</I>
849 
</PRE>
850 
</P>
851 
 
852 
<HR>
853 
<H3><A NAME="macro">2.2.16. Macro definitions</A></H3>
854 
<P>
855 
By default, multiple consistent definitions of a macro are allowed.
856 
This behaviour can be controlled using the directive:
857 
<PRE>
858 
	#pragma TenDRA extra macro definition <I>allow</I>
859 
</PRE>
860 
The ISO C/C++ rules for determining whether two macro definitions
861 
are consistent are fairly restrictive.  A more relaxed rule allowing
862 
for consistent renaming of macro parameters can be enabled using:
863 
<PRE>
864 
	#pragma TenDRA weak macro equality <I>allow</I>
865 
</PRE>
866 
</P>
867 
<P>
868 
In the definition of macros with parameters, a <CODE>#</CODE> in the
869 
replacement list must be followed by a parameter name, indicating
870 
the stringising operation.  This behaviour can be controlled by the
871 
directive:
872 
<PRE>
873 
	#pragma TenDRA no ident after # <I>allow</I>
874 
</PRE>
875 
which allows a <CODE>#</CODE> which is not followed by a parameter
876 
name to be treated as a normal preprocessing token.
877 
</P>
878 
<P>
879 
In a list of macro arguments, the effect of a sequence of preprocessing
880 
tokens which otherwise resembles a preprocessing directive is undefined.
881 
The C++ producer treats such directives as normal sequences of preprocessing
882 
tokens, but can be made to report such behaviour using:
883 
<PRE>
884 
	#pragma TenDRA directive as macro argument <I>allow</I>
885 
</PRE>
886 
</P>
887 
 
888 
<HR>
889 
<H3><A NAME="empty">2.2.17. Empty source files</A></H3>
890 
<P>
891 
ISO C requires that a translation unit should contain at least one
892 
declaration.  C++ and older dialects of C allow translation units
893 
which contain no declarations.  This behaviour can be controlled using
894 
the directive:
895 
<PRE>
896 
	#pragma TenDRA no external declaration <I>allow</I>
897 
</PRE>
898 
</P>
899 
 
900 
<HR>
901 
<H3><A NAME="std">2.2.18. The <CODE>std</CODE> namespace</A></H3>
902 
<P>
903 
Several classes declared in the <CODE>std</CODE> namespace arise naturally
904 
as part of the C++ language specification.  These are as follows:
905 
<PRE>
906 
	std::type_info		// type of typeid construct
907 
	std::bad_cast		// thrown by dynamic_cast construct
908 
	std::bad_typeid		// thrown by typeid construct
909 
	std::bad_alloc		// thrown by new construct
910 
	std::bad_exception	// used in exception specifications
911 
</PRE>
912 
The definitions of these classes are found, when needed, by looking
913 
up the appropriate class name in the <CODE>std</CODE> namespace.
914 
Depending on the context, an error may be reported if the class is
915 
not found. It is possible to modify the namespace which is searched
916 
for these classes using the directive:
917 
<PRE>
918 
	#pragma TenDRA++ set std namespace : <I>scope-name</I>
919 
</PRE>
920 
where <I>scope-name</I> can be an identifier giving a namespace name
921 
or <CODE>::</CODE>, indicating the global namespace.
922 
</P>
923 
 
924 
<HR>
925 
<H3><A NAME="linkage">2.2.19. Object linkage</A></H3>
926 
<P>
927 
If an object is declared with both external and internal linkage in
928 
the same translation unit then, by default, an error is given.  This
929 
behaviour can be changed using the directive:
930 
<PRE>
931 
	#pragma TenDRA incompatible linkage <I>allow</I>
932 
</PRE>
933 
When incompatible linkages are allowed, whether the resultant identifier
934 
has external or internal linkage can be set using one of the directives:
935 
<PRE>
936 
	#pragma TenDRA linkage resolution : off
937 
	#pragma TenDRA linkage resolution : (external) <I>on</I>
938 
	#pragma TenDRA linkage resolution : (internal) <I>on</I>
939 
</PRE>
940 
</P>
941 
<P>
942 
It is possible to declare objects with external linkage in a block.
943 
C leaves it undefined whether declarations of the same object in different
944 
blocks, such as:
945 
<PRE>
946 
	void f ()
947 
	{
948 
	    extern int a ;
949 
	    ....
950 
	}
951 
 
952 
	void g ()
953 
	{
954 
	    extern double a ;
955 
	    ....
956 
	}
957 
</PRE>
958 
are checked for compatibility.  However in C++ the one definition
959 
rule implies that such declarations are indeed checked for compatibility.
960 
The status of this check can be set using the directive:
961 
<PRE>
962 
	#pragma TenDRA unify external linkage <I>on</I>
963 
</PRE>
964 
Note that it is not possible in ISO C or C++ to declare objects or
965 
functions with internal linkage in a block.  While <CODE>static</CODE>
966 
object definitions in a block have a specific meaning, there is no
967 
real reason why <CODE>static</CODE> functions should not be declared
968 
in a block.  This behaviour can be enabled using the directive:
969 
<PRE>
970 
	#pragma TenDRA block function static <I>allow</I>
971 
</PRE>
972 
</P>
973 
<P>
974 
Inline functions have external linkage by default in ISO C++, but
975 
internal linkage in older dialects.  The default linkage can be set
976 
using the directive:
977 
<PRE>
978 
	#pragma TenDRA++ inline linkage <I>linkage-spec</I>
979 
</PRE>
980 
where <I>linkage-spec</I> can be <CODE>external</CODE> or
981 
<CODE>internal</CODE>.  Similarly <CODE>const</CODE> objects have
982 
internal linkage by default in C++, but external linkage in C.  The
983 
default linkage can be set using the directive:
984 
<PRE>
985 
	#pragma TenDRA++ const linkage <I>linkage-spec</I>
986 
</PRE>
987 
</P>
988 
<P>
989 
Older dialects of C treated all identifiers with external linkage
990 
as if they had been declared <CODE>volatile</CODE> (i.e. by being
991 
conservative in optimising such values).  This behaviour can be enabled
992 
using the directive:
993 
<PRE>
994 
	#pragma TenDRA external volatile_t
995 
</PRE>
996 
</P>
997 
<P>
998 
It is possible to set the default language linkage using the directive:
999 
<PRE>
1000 
	#pragma TenDRA++ external linkage <I>string-literal</I>
1001 
</PRE>
1002 
This is equivalent to enclosing the rest of the current checking scope
1003 
in:
1004 
<PRE>
1005 
	extern <I>string-literal</I> {
1006 
	    ....
1007 
	}
1008 
</PRE>
1009 
It is unspecified what happens if such a directive is used within
1010 
an explicit linkage specification and does not nest correctly.  This
1011 
directive is particularly useful when used in a <A HREF="#scope">named
1012 
environment</A> associated with an include directory.  For example,
1013 
it can be used to express the fact that all the objects declared in
1014 
headers included from that directory have C linkage.
1015 
</P>
1016 
<P>
1017 
A change in ISO C++ relative to older dialects is that the language
1018 
linkage of a function now forms part of the function type.  For example:
1019 
<PRE>
1020 
	extern &quot;C&quot; int f ( int ) ;
1021 
	int ( *pf ) ( int ) = f ;		// error
1022 
</PRE>
1023 
The directive:
1024 
<PRE>
1025 
	#pragma TenDRA++ external function linkage <I>on</I>
1026 
</PRE>
1027 
can be used to control whether function types with differing language
1028 
linkages, but which are otherwise compatible, are considered compatible
1029 
or not.
1030 
</P>
1031 
 
1032 
<HR>
1033 
<H3><A NAME="static">2.2.20. Static identifiers</A></H3>
1034 
<P>
1035 
By default, objects and functions with internal linkage are mapped
1036 
to tags without external names in the output TDF capsule.  Thus such
1037 
names are not available to the installer and it needs to make up internal
1038 
names to represent such objects in its output.  This is not desirable
1039 
in such operations as profiling, where a meaningful internal name
1040 
is needed to make sense of the output.  The directive:
1041 
<PRE>
1042 
	#pragma TenDRA preserve <I>identifier-list</I>
1043 
</PRE>
1044 
can be used to preserve the names of the given list of identifiers
1045 
with internal linkage.  This is done using the <CODE>static_name_def</CODE>
1046 
TDF construct.  The form:
1047 
<PRE>
1048 
	#pragma TenDRA preserve *
1049 
</PRE>
1050 
will preserve the names of all identifiers with internal linkage in
1051 
this way.
1052 
</P>
1053 
 
1054 
<HR>
1055 
<H3><A NAME="decl_none">2.2.21. Empty declarations</A></H3>
1056 
<P>
1057 
ISO C++ requires every declaration or member declaration to introduce
1058 
one or more names into the program.  The directive:
1059 
<PRE>
1060 
	#pragma TenDRA unknown struct/union <I>allow</I>
1061 
</PRE>
1062 
can be used to relax one particular instance of this rule, by allowing
1063 
anonymous class definitions (recall that anonymous unions are objects,
1064 
not types, in C++ and so are not covered by this rule).  The C++ grammar
1065 
also allows a solitary semicolon as a declaration or member declaration;
1066 
however such a declaration does not introduce a name and so contravenes
1067 
the rule above.  The rule can be relaxed in this case using the directive:
1068 
<PRE>
1069 
	#pragma TenDRA extra ; <I>allow</I>
1070 
</PRE>
1071 
Note that the C++ grammar explicitly allows for an extra semicolon
1072 
following an inline member function definition, but that semicolons
1073 
following other function definitions are actually empty declarations
1074 
of the form above.  A solitary semicolon in a statement is interpreted
1075 
as an empty expression statement rather than an empty declaration
1076 
statement.
1077 
</P>
1078 
 
1079 
<HR>
1080 
<H3><A NAME="implicit">2.2.22. Implicit <CODE>int</CODE></A></H3>
1081 
<P>
1082 
The C &quot;implicit <CODE>int</CODE>&quot; rule, whereby a type of
1083 
<CODE>int</CODE>
1084 
is inferred in a list of type or declaration specifiers which does
1085 
not contain a type name, has been removed in ISO C++, although it
1086 
was supported in older dialects of C++.  This check is controlled
1087 
by the directive:
1088 
<PRE>
1089 
	#pragma TenDRA++ implicit int type <I>allow</I>
1090 
</PRE>
1091 
Partial relaxations of this rules are allowed.  The directive:
1092 
<PRE>
1093 
	#pragma TenDRA++ implicit int type for const/volatile <I>allow</I>
1094 
</PRE>
1095 
will allow for implicit <CODE>int</CODE> when the list of type specifiers
1096 
contains a cv-qualifier.  Similarly the directive:
1097 
<PRE>
1098 
	#pragma TenDRA implicit int type for function return <I>allow</I>
1099 
</PRE>
1100 
will allow for implicit <CODE>int</CODE> in the return type of a function
1101 
definition (this excludes constructors, destructors and conversion
1102 
functions, where special rules apply).  A function definition is the
1103 
only kind of declaration in ISO C where a declaration specifier is
1104 
not required. Older dialects of C allowed declaration specifiers to
1105 
be omitted in other cases.  Support for this behaviour can be enabled
1106 
using:
1107 
<PRE>
1108 
	#pragma TenDRA implicit int type for external declaration <I>allow</I>
1109 
</PRE>
1110 
The four cases can be demonstrated in the following example:
1111 
<PRE>
1112 
	extern a ;		// implicit int
1113 
	const b = 1 ;		// implicit const int
1114 
 
1115 
	f ()			// implicit function return
1116 
	{
1117 
	    return 2 ;
1118 
	}
1119 
 
1120 
	c = 3 ;			// error: not allowed in C++
1121 
</PRE>
1122 
</P>
1123 
 
1124 
<HR>
1125 
<H3><A NAME="longlong">2.2.23. Extended integral types</A></H3>
1126 
<P>
1127 
The <CODE>long long</CODE> integral types are not part of ISO C or
1128 
C++ by default, however support for them can be enabled using the
1129 
directive:
1130 
<PRE>
1131 
	#pragma TenDRA longlong type <I>allow</I>
1132 
</PRE>
1133 
This support includes allowing <CODE>long long</CODE> in type specifiers
1134 
and allowing <CODE>LL</CODE> and <CODE>ll</CODE> as integer literal
1135 
suffixes.
1136 
</P>
1137 
<P>
1138 
There is a further directive given by the two cases:
1139 
<PRE>
1140 
	#pragma TenDRA set longlong type : long long
1141 
	#pragma TenDRA set longlong type : long
1142 
</PRE>
1143 
which can be used to control the implementation of the <CODE>long
1144 
long</CODE> types.  Either they can be mapped to the
1145 
<A HREF="lib.html#arith">default representation</A>, which is guaranteed
1146 
to contain at least 64 bits, or they can be mapped to the corresponding
1147 
<CODE>long</CODE> types.
1148 
</P>
1149 
<P>
1150 
Because these <CODE>long long</CODE> types are not an intrinsic part
1151 
of C++ the implementation does not integrate them into the language
1152 
as fully as is possible.  This is to prevent the presence or otherwise
1153 
of
1154 
<CODE>long long</CODE> types affecting the semantics of code which
1155 
does not use them.  For example, it would be possible to extend the
1156 
rules for the types of integer literals, integer promotion types and
1157 
arithmetic types to say that if the given value does not fit into
1158 
the standard integral types then the extended types are tried.  This
1159 
has not been done, although these rules could be implemented by changing
1160 
the definitions of the <A HREF="lib.html#arith">standard tokens</A>
1161 
used to determine these types.  By default, only the rules for arithmetic
1162 
types involving a <CODE>long long</CODE> operand and for <CODE>LL</CODE>
1163 
integer literals mention <CODE>long long</CODE> types.
1164 
</P>
1165 
 
1166 
<HR>
1167 
<H3><A NAME="bitfield">2.2.24. Bitfield types</A></H3>
1168 
<P>
1169 
The C++ rules on bitfield types differ slightly from the C rules.
1170 
Firstly any integral or enumeration type is allowed in a bitfield,
1171 
and secondly the bitfield width may exceed the underlying type size
1172 
(the extra bits being treated as padding).  These properties can be
1173 
controlled using the directives:
1174 
<PRE>
1175 
	#pragma TenDRA extra bitfield int type <I>allow</I>
1176 
	#pragma TenDRA bitfield overflow <I>allow</I>
1177 
</PRE>
1178 
respectively.
1179 
</P>
1180 
 
1181 
<HR>
1182 
<H3><A NAME="elab">2.2.25. Elaborated type specifiers</A></H3>
1183 
<P>
1184 
In elaborated type specifiers, the class key (<CODE>class</CODE>,
1185 
<CODE>struct</CODE>, <CODE>union</CODE> or <CODE>enum</CODE>) should
1186 
agree with any previous declaration of the type (except that <CODE>class</CODE>
1187 
and <CODE>struct</CODE> are interchangeable).  This requirement can
1188 
be relaxed using the directive:
1189 
<PRE>
1190 
	#pragma TenDRA ignore struct/union/enum tag <I>on</I>
1191 
</PRE>
1192 
</P>
1193 
<P>
1194 
In ISO C and C++ it is not possible to give a forward declaration
1195 
of an enumeration type.  This constraint can be relaxed using the
1196 
directive:
1197 
<PRE>
1198 
	#pragma TenDRA forward enum declaration <I>allow</I>
1199 
</PRE>
1200 
Until the end of its definition, an enumeration type is treated as
1201 
an incomplete type (as with class types).  In enumeration definitions,
1202 
and a couple of other contexts where comma-separated lists are required,
1203 
the directive:
1204 
<PRE>
1205 
	#pragma TenDRA extra , <I>allow</I>
1206 
</PRE>
1207 
can be used to allow a trailing comma at the end of the list.
1208 
</P>
1209 
<P>
1210 
The directive:
1211 
<PRE>
1212 
	#pragma TenDRA complete struct/union analysis <I>on</I>
1213 
</PRE>
1214 
can be used to enable a check that every class or union has been completed
1215 
within each translation unit in which it is declared.
1216 
</P>
1217 
 
1218 
<HR>
1219 
<H3><A NAME="impl_func">2.2.26. Implicit function declarations</A></H3>
1220 
<P>
1221 
C, but not C++, allows calls to undeclared functions, the function
1222 
being declared implicitly.  It is possible to enable support for implicit
1223 
function declarations using the directive:
1224 
<PRE>
1225 
	#pragma TenDRA implicit function declaration <I>on</I>
1226 
</PRE>
1227 
Such implicitly declared functions have C linkage and type
1228 
<CODE>int ( ... )</CODE>.
1229 
</P>
1230 
 
1231 
<HR>
1232 
<H3><A NAME="weak">2.2.27. Weak function prototypes</A></H3>
1233 
<P>
1234 
The C producer supports a concept, weak prototypes, whereby type checking
1235 
can be applied to the arguments of a non-prototype function.  This
1236 
checking can be enabled using the directive:
1237 
<PRE>
1238 
	#pragma TenDRA weak prototype analysis <I>on</I>
1239 
</PRE>
1240 
The concept of weak prototypes is not applicable to C++, where all
1241 
functions are prototyped.  The C++ producer does allow the syntax
1242 
for explicit weak prototype declarations, but treats them as if they
1243 
were normal prototypes.  These declarations are denoted by means of
1244 
a keyword,
1245 
<CODE>WEAK</CODE> say, introduced by the directive:
1246 
<PRE>
1247 
	#pragma TenDRA keyword <I>identifier</I> for weak
1248 
</PRE>
1249 
preceding the <CODE>(</CODE> of the function declarator.  The directives:
1250 
<PRE>
1251 
	#pragma TenDRA prototype <I>allow</I>
1252 
	#pragma TenDRA prototype (weak) <I>allow</I>
1253 
</PRE>
1254 
which can be used in the C producer to warn of prototype or weak prototype
1255 
declarations, are similarly ignored by the C++ producer.
1256 
</P>
1257 
<P>
1258 
The C producer also allows the directives:
1259 
<PRE>
1260 
	#pragma TenDRA argument <I>type-id</I> as <I>type-id</I>
1261 
	#pragma TenDRA argument <I>type-id</I> as ...
1262 
	#pragma TenDRA extra ... <I>allow</I>
1263 
	#pragma TenDRA incompatible promoted function argument <I>allow</I>
1264 
</PRE>
1265 
which control the compatibility of function types.  These directives
1266 
are ignored by the C++ producer (some of them would make sense in
1267 
the context of C++ but would over-complicate function overloading).
1268 
</P>
1269 
 
1270 
<HR>
1271 
<H3><A NAME="printf">2.2.28. <CODE>printf</CODE> and <CODE>scanf</CODE>
1272 
argument checking</A></H3>
1273 
<P>
1274 
The C producer includes a number of checks that the arguments in a
1275 
call to a function in the <CODE>printf</CODE> or <CODE>scanf</CODE>
1276 
families match the given format string.  The check is implemented
1277 
by using the directives:
1278 
<PRE>
1279 
	#pragma TenDRA type <I>identifier</I> for ... printf
1280 
	#pragma TenDRA type <I>identifier</I> for ... scanf
1281 
</PRE>
1282 
to introduce a type representing a <CODE>printf</CODE> or <CODE>scanf</CODE>
1283 
format string.  For most purposes this type is treated as <CODE>const
1284 
char *</CODE>, but when it appears in a function declaration it alerts
1285 
the producer that any extra arguments passed to that function should
1286 
match the format string passed as the corresponding argument.  The
1287 
TenDRA API headers conditionally declare <CODE>printf</CODE>,
1288 
<CODE>scanf</CODE> and similar functions in something like the form:
1289 
<PRE>
1290 
	#ifdef __NO_PRINTF_CHECKS
1291 
	typedef const char *__printf_string ;
1292 
	#else
1293 
	#pragma TenDRA type __printf_string for ... printf
1294 
	#endif
1295 
 
1296 
	int printf ( __printf_string, ... ) ;
1297 
	int fprintf ( FILE *, __printf_string, ... ) ;
1298 
	int sprintf ( char *, __printf_string, ... ) ;
1299 
</PRE>
1300 
These declarations can be skipped, effectively disabling this check,
1301 
by defining the <CODE>__NO_PRINTF_CHECKS</CODE> macro.
1302 
</P>
1303 
<P>
1304 
<IMG SRC="../images/warn.gif" ALT="warning">
1305 
These <CODE>printf</CODE> and <CODE>scanf</CODE> format string checks
1306 
have not yet been implemented in the C++ producer due to presence
1307 
of an alternative, type checked, I/O package - namely
1308 
<CODE>&lt;iostream&gt;</CODE>.  The format string types are simply
1309 
treated as <CODE>const char *</CODE>.
1310 
</P>
1311 
 
1312 
<HR>
1313 
<H3><A NAME="typedef">2.2.29. Type declarations</A></H3>
1314 
<P>
1315 
C does not allow multiple definitions of a <CODE>typedef</CODE> name,
1316 
whereas C++ allows multiple consistent definitions.  This behaviour
1317 
can be controlled using the directive:
1318 
<PRE>
1319 
	#pragma TenDRA extra type definition <I>allow</I>
1320 
</PRE>
1321 
</P>
1322 
 
1323 
<HR>
1324 
<H3><A NAME="compatible">2.2.30. Type compatibility</A></H3>
1325 
<P>
1326 
The directive:
1327 
<PRE>
1328 
	#pragma TenDRA incompatible type qualifier <I>allow</I>
1329 
</PRE>
1330 
allows objects to be redeclared with different cv-qualifiers (normally
1331 
such redeclarations would be incompatible).  The composite type is
1332 
qualified using the join of the cv-qualifiers in the various redeclarations.
1333 
</P>
1334 
<P>
1335 
The directive:
1336 
<PRE>
1337 
	#pragma TenDRA compatible type : <I>type-id</I> == <I>type-id</I> : <I>allow
1338 
</I>
1339 
</PRE>
1340 
asserts that the given two types are compatible.  Currently the only
1341 
implemented version is <CODE>char * == void *</CODE> which enables
1342 
<CODE>char *</CODE> to be used as a generic pointer as it was in older
1343 
dialects of C.
1344 
</P>
1345 
 
1346 
<HR>
1347 
<H3><A NAME="complete">2.2.31. Incomplete types</A></H3>
1348 
<P>
1349 
Some dialects of C allow incomplete arrays as member types.  These
1350 
are generally used as a place-holder at the end of a structure to
1351 
allow for the allocation of an arbitrarily sized array.  Support for
1352 
this feature can be enabled using the directive:
1353 
<PRE>
1354 
	#pragma TenDRA incomplete type as object type <I>allow</I>
1355 
</PRE>
1356 
</P>
1357 
 
1358 
<HR>
1359 
<H3><A NAME="conv">2.2.32. Type conversions</A></H3>
1360 
<P>
1361 
There are a number of directives which allow various classes of type
1362 
conversion to be checked.  The directives:
1363 
<PRE>
1364 
	#pragma TenDRA conversion analysis (int-int explicit) <I>on</I>
1365 
	#pragma TenDRA conversion analysis (int-int implicit) <I>on</I>
1366 
</PRE>
1367 
will check for unsafe explicit or implicit conversions between arithmetic
1368 
types.  Similarly conversions between pointers and arithmetic types
1369 
can be checked using:
1370 
<PRE>
1371 
	#pragma TenDRA conversion analysis (int-pointer explicit) <I>on</I>
1372 
	#pragma TenDRA conversion analysis (int-pointer implicit) <I>on</I>
1373 
</PRE>
1374 
or equivalently:
1375 
<PRE>
1376 
	#pragma TenDRA conversion analysis (pointer-int explicit) <I>on</I>
1377 
	#pragma TenDRA conversion analysis (pointer-int implicit) <I>on</I>
1378 
</PRE>
1379 
Conversions between pointer types can be checked using:
1380 
<PRE>
1381 
	#pragma TenDRA conversion analysis (pointer-pointer explicit) <I>on</I>
1382 
	#pragma TenDRA conversion analysis (pointer-pointer implicit) <I>on</I>
1383 
</PRE>
1384 
</P>
1385 
<P>
1386 
There are some further variants which can be used to enable useful
1387 
sets of conversion checks.  For example:
1388 
<PRE>
1389 
	#pragma TenDRA conversion analysis (int-int) <I>on</I>
1390 
</PRE>
1391 
enables both implicit and explicit arithmetic conversion checks.
1392 
The directives:
1393 
<PRE>
1394 
	#pragma TenDRA conversion analysis (int-pointer) <I>on</I>
1395 
	#pragma TenDRA conversion analysis (pointer-int) <I>on</I>
1396 
	#pragma TenDRA conversion analysis (pointer-pointer) <I>on</I>
1397 
</PRE>
1398 
are equivalent to their corresponding explicit forms (because the
1399 
implicit forms are illegal by default).  The directive:
1400 
<PRE>
1401 
	#pragma TenDRA conversion analysis <I>on</I>
1402 
</PRE>
1403 
is equivalent to the four directives just given.  It enables checks
1404 
on implicit and explicit arithmetic conversions, explicit arithmetic
1405 
to pointer conversions and explicit pointer conversions.
1406 
</P>
1407 
<P>
1408 
The default settings for these checks are determined by the implicit
1409 
and explicit conversions allowed in C++.  Note that there are differences
1410 
between the conversions allowed in C and C++.  For example, an arithmetic
1411 
type can be converted implicitly to an enumeration type in C, but
1412 
not in C++.  The directive:
1413 
<PRE>
1414 
	#pragma TenDRA conversion analysis (int-enum implicit) <I>on</I>
1415 
</PRE>
1416 
can be used to control the status of this conversion.  The level of
1417 
severity for an error message arising from such a conversion is the
1418 
maximum of the severity set by this directive and that set by the
1419 
<CODE>int-int implicit</CODE> directive above.
1420 
</P>
1421 
<P>
1422 
The implicit pointer conversions described above do not include conversions
1423 
to and from the generic pointer <CODE>void *</CODE>, which have their
1424 
own controlling directives.  A pointer of type <CODE>void *</CODE>
1425 
can be converted implicitly to another pointer type in C but not in
1426 
C++; this is controlled by the directive:
1427 
<PRE>
1428 
	#pragma TenDRA++ conversion analysis (void*-pointer implicit) <I>on</I>
1429 
</PRE>
1430 
The reverse conversion, from a pointer type to <CODE>void *</CODE>
1431 
is allowed in both C and C++, and has a controlling directive:
1432 
<PRE>
1433 
	#pragma TenDRA++ conversion analysis (pointer-void* implicit) <I>on</I>
1434 
</PRE>
1435 
</P>
1436 
<P>
1437 
In ISO C and C++, a function pointer can only be cast to other function
1438 
pointers, not to object pointers or <CODE>void *</CODE>.  Many dialects
1439 
however allow function pointers to be cast to and from other pointers.
1440 
This behaviour can be controlled using the directive:
1441 
<PRE>
1442 
	#pragma TenDRA function pointer as pointer <I>allow</I>
1443 
</PRE>
1444 
which causes function pointers to be treated in the same way as all
1445 
other pointers.
1446 
</P>
1447 
<P>
1448 
The integer conversion checks described above only apply to unsafe
1449 
conversions.  A simple-minded check for shortening conversions is
1450 
not adequate, as is shown by the following example:
1451 
<PRE>
1452 
	char a = 1, b = 2 ;
1453 
	char c = a + b ;
1454 
</PRE>
1455 
the sum <CODE>a + b</CODE> is evaluated as an <CODE>int</CODE> which
1456 
is then shortened to a <CODE>char</CODE>.  Any check which does not
1457 
distinguish this sort of &quot;safe&quot; shortening conversion from
1458 
unsafe shortening conversions such as:
1459 
<PRE>
1460 
	int a = 1, b = 2 ;
1461 
	char c = a + b ;
1462 
</PRE>
1463 
is not likely to be very useful.  The producer therefore associates
1464 
two types with each integral expression; the first is the normal,
1465 
representation type and the second is the underlying, semantic type.
1466 
Thus in the first example, the representation type of <CODE>a + b</CODE>
1467 
is <CODE>int</CODE>, but semantically it is still a <CODE>char</CODE>.
1468 
The conversion analysis is based on the semantic types.
1469 
</P>
1470 
<P>
1471 
<IMG SRC="../images/warn.gif" ALT="warning">
1472 
The C producer supports a directive:
1473 
<PRE>
1474 
	#pragma TenDRA keyword <I>identifier</I> for type representation
1475 
</PRE>
1476 
whereby a keyword can be introduced which can be used to explicitly
1477 
declare a type with given representation and semantic components.
1478 
Unfortunately this makes the <A HREF="parse.html">C++ grammar</A>
1479 
ambiguous, so it has not yet been implemented in the C++ producer.
1480 
</P>
1481 
<P>
1482 
It is possible to allow individual conversions by means of conversion
1483 
tokens.  A <A HREF="token.html">procedure token</A> which takes one
1484 
rvalue expression program parameter and returns an rvalue expression,
1485 
such as:
1486 
<PRE>
1487 
	#pragma token PROC ( EXP : t : ) EXP : s : conv #
1488 
</PRE>
1489 
can be regarded as mapping expressions of type <CODE>t</CODE> to expressions
1490 
of type <CODE>s</CODE>.  The directive:
1491 
<PRE>
1492 
	#pragma TenDRA conversion <I>identifier-list</I> allow
1493 
</PRE>
1494 
can be used to nominate such a token as a conversion token.  That
1495 
is to say, if the conversion, whether explicit or implicit, from <CODE>t</CODE>
1496 
to <CODE>s</CODE> cannot be done by other means, it is done by applying
1497 
the token <CODE>conv</CODE>, so:
1498 
<PRE>
1499 
	t a ;
1500 
	s b = a ;		// maps to conv ( a )
1501 
</PRE>
1502 
Note that, unlike conversion functions, conversion tokens can be applied
1503 
to any types.
1504 
</P>
1505 
 
1506 
<HR>
1507 
<H3><A NAME="cast">2.2.33. Cast expressions</A></H3>
1508 
<P>
1509 
ISO C++ introduces the constructs <CODE>static_cast</CODE>,
1510 
<CODE>const_cast</CODE> and <CODE>reinterpret_cast</CODE>, which can
1511 
be used in various contexts where an old style explicit cast would
1512 
previously have been used.  By default, an explicit cast can perform
1513 
any combination of the conversions performed by these three constructs.
1514 
To aid migration to the new style casts the directives:
1515 
<PRE>
1516 
	#pragma TenDRA++ explicit cast as <I>cast-state allow</I>
1517 
	#pragma TenDRA++ explicit cast <I>allow</I>
1518 
</PRE>
1519 
where <I>cast-state</I> is defined as follows:
1520 
<PRE>
1521 
	<I>cast-state</I> :
1522 
		static_cast
1523 
		const_cast
1524 
		reinterpret_cast
1525 
		static_cast | <I>cast-state</I>
1526 
		const_cast | <I>cast-state</I>
1527 
		reinterpret_cast | <I>cast-state</I>
1528 
</PRE>
1529 
can be used to restrict the conversions which can be performed using
1530 
explicit casts.  The first form sets the interpretation of explicit
1531 
cast to be combinations of the given constructs; the second resets
1532 
the interpretation to the default.  For example:
1533 
<PRE>
1534 
	#pragma TenDRA++ explicit cast as static_cast | const_cast allow
1535 
</PRE>
1536 
means that conversions requiring <CODE>reinterpret_cast</CODE> (the
1537 
most unportable conversions) will not be allowed to be performed using
1538 
explicit casts, but will have to be given as a <CODE>reinterpret_cast</CODE>
1539 
construct.  Changing <CODE>allow</CODE> to <CODE>warning</CODE> will
1540 
also cause a warning to be issued for every explicit cast expression.
1541 
</P>
1542 
 
1543 
<HR>
1544 
<H3><A NAME="ellipsis">2.2.34. Ellipsis functions</A></H3>
1545 
<P>
1546 
The directive:
1547 
<PRE>
1548 
	#pragma TenDRA ident ... <I>allow</I>
1549 
</PRE>
1550 
may be used to enable or disable the use of <CODE>...</CODE> as a
1551 
primary expression in a function defined with ellipsis.  The type
1552 
of such an expression is implementation defined.  This expression
1553 
is used in the definition of the <A HREF="lib.html#ellipsis"><CODE>va_start
1554 
</CODE>
1555 
macro</A> in the <CODE>&lt;stdarg.h&gt;</CODE> header.  This header
1556 
automatically enables this switch.
1557 
</P>
1558 
 
1559 
<HR>
1560 
<H3><A NAME="overload">2.2.35. Overloaded functions</A></H3>
1561 
<P>
1562 
Older dialects of C++ did not report ambiguous overloaded function
1563 
resolutions, but instead resolved the call to the first of the most
1564 
viable candidates to be declared.  This behaviour can be controlled
1565 
using the directive:
1566 
<PRE>
1567 
	#pragma TenDRA++ ambiguous overload resolution <I>allow</I>
1568 
</PRE>
1569 
There are occasions when the resolution of an overloaded function
1570 
call is not clear.  The directive:
1571 
<PRE>
1572 
	#pragma TenDRA++ overload resolution <I>allow</I>
1573 
</PRE>
1574 
can be used to report the resolution of any such call (whether explicit
1575 
or implicit) where there is more than one viable candidate.
1576 
</P>
1577 
<P>
1578 
An interesting consequence of compiling C++ in a target independent
1579 
manner is that certain overload resolutions can only be determined
1580 
at install-time. For example, in:
1581 
<PRE>
1582 
	int f ( int ) ;
1583 
	int f ( unsigned int ) ;
1584 
	int f ( long ) ;
1585 
	int f ( unsigned long ) ;
1586 
 
1587 
	int a = f ( sizeof ( int ) ) ;	// which f?
1588 
</PRE>
1589 
the type of the <CODE>sizeof</CODE> operator, <CODE>size_t</CODE>,
1590 
is target dependent, but its promotion must be one of the types
1591 
<CODE>int</CODE>, <CODE>unsigned int</CODE>, <CODE>long</CODE> or
1592 
<CODE>unsigned long</CODE>.  Thus the call to <CODE>f</CODE> always
1593 
has a unique resolution, but what it is is target dependent.  The
1594 
equivalent directives:
1595 
<PRE>
1596 
	#pragma TenDRA++ conditional overload resolution <I>allow</I>
1597 
	#pragma TenDRA++ conditional overload resolution (complete) <I>allow</I>
1598 
</PRE>
1599 
can be used to warn about such target dependent overload resolutions.
1600 
By default, such resolutions are only allowed if there is a unique
1601 
resolution for each possible implementation of the argument types
1602 
(note that, for simplicity, the possibility of <CODE>long long</CODE>
1603 
implementation types is ignored).  The directive:
1604 
<PRE>
1605 
	#pragma TenDRA++ conditional overload resolution (incomplete) <I>allow</I>
1606 
</PRE>
1607 
can be used to allow target dependent overload resolutions which only
1608 
have resolutions for some of the possible implementation types (if
1609 
one of the <CODE>f</CODE> declarations above was removed, for example).
1610 
If the implementation does not match one of these types then an install-time
1611 
error is given.
1612 
</P>
1613 
<P>
1614 
There are restrictions on the set of candidate functions involved
1615 
in a target dependent overload resolution.  Most importantly, it should
1616 
be possible to bring their return types to a common type, as if by
1617 
a series of <CODE>?:</CODE> operations.  This common type is the type
1618 
of the target dependent call.  By this means, target dependent types
1619 
are prevented from propagating further out into the program.  Note
1620 
that since sets of overloaded functions usually have the same semantics,
1621 
this does not usually present a problem.
1622 
</P>
1623 
 
1624 
<HR>
1625 
<H3><A NAME="exp">2.2.36. Expressions</A></H3>
1626 
<P>
1627 
The directive:
1628 
<PRE>
1629 
	#pragma TenDRA operator precedence analysis <I>on</I>
1630 
</PRE>
1631 
can be used to enable a check for expressions where the operator precedence
1632 
is not necessarily what might be expected.  The intended precedence
1633 
can be clarified by means of explicit parentheses.  The precedence
1634 
levels checked are as follows:
1635 
<OL>
1636 
<LI><CODE>&amp;&amp;</CODE> versus <CODE>||</CODE>.
1637 
<LI><CODE>&lt;&lt;</CODE> and <CODE>&gt;&gt;</CODE> versus binary
1638 
<CODE>+</CODE> and <CODE>-</CODE>.
1639 
<LI>Binary <CODE>&amp;</CODE> versus binary <CODE>+</CODE>,     <CODE>-</CODE>,
1640 
<CODE>==</CODE>, <CODE>!=</CODE>, <CODE>&gt;</CODE>,     <CODE>&gt;=</CODE>,
1641 
<CODE>&lt;</CODE> and <CODE>&lt;=</CODE>.
1642 
<LI><CODE>^</CODE> versus binary <CODE>&amp;</CODE>, <CODE>+</CODE>,
1643 
<CODE>-</CODE>, <CODE>==</CODE>, <CODE>!=</CODE>, <CODE>&gt;</CODE>,
1644 
<CODE>&gt;=</CODE>, <CODE>&lt;</CODE> and <CODE>&lt;=</CODE>.
1645 
<LI><CODE>|</CODE> versus binary <CODE>^</CODE>, <CODE>&amp;</CODE>,
1646 
<CODE>+</CODE>, <CODE>-</CODE>, <CODE>==</CODE>, <CODE>!=</CODE>,
1647 
<CODE>&gt;</CODE>, <CODE>&gt;=</CODE>, <CODE>&lt;</CODE> and     <CODE>&lt;=
1648 
</CODE>.
1649 
</OL>
1650 
Also checked are expressions such as <CODE>a &lt; b &lt; c</CODE>
1651 
which do not have their normal mathematical meaning.  For example,
1652 
in:
1653 
<PRE>
1654 
	d = a &lt;&lt; b + c ;	// precedence is a &lt;&lt; ( b + c )
1655 
</PRE>
1656 
the precedence is counter-intuitive, although strangely enough, it
1657 
isn't in:
1658 
<PRE>
1659 
	cout &lt;&lt; b + c ;		// precedence is cout &lt;&lt; ( b + c )
1660 
</PRE>
1661 
</P>
1662 
<P>
1663 
Other dubious arithmetic operations can be checked for using the directive:
1664 
<PRE>
1665 
	#pragma TenDRA integer operator analysis <I>on</I>
1666 
</PRE>
1667 
This includes checks for operations, such as division by a negative
1668 
value, which are implementation dependent, and those such as testing
1669 
whether an unsigned value is less than zero, which serve no purpose.
1670 
Similarly the directive:
1671 
<PRE>
1672 
	#pragma TenDRA++ pointer operator analysis <I>on</I>
1673 
</PRE>
1674 
checks for dubious pointer operations.  This includes very simple
1675 
bounds checking for arrays and checking that only the simple literal
1676 
<CODE>0</CODE>
1677 
is used in null pointer constants:
1678 
<PRE>
1679 
	char *p = 1 - 1 ;	// valid, but weird
1680 
</PRE>
1681 
</P>
1682 
<P>
1683 
The directive:
1684 
<PRE>
1685 
	#pragma TenDRA integer overflow analysis <I>on</I>
1686 
</PRE>
1687 
is used to control the treatment of overflows in the evaluation of
1688 
integer constant expressions.  This includes the detection of division
1689 
by zero.
1690 
</P>
1691 
 
1692 
<HR>
1693 
<H3><A NAME="init">2.2.37. Initialiser expressions</A></H3>
1694 
<P>
1695 
C, but not C++, only allows constant expressions in static initialisers.
1696 
The directive:
1697 
<PRE>
1698 
	#pragma TenDRA variable initialization <I>allow</I>
1699 
</PRE>
1700 
can be enable support for C++-style dynamic initialisers.  Conversely,
1701 
it can be used in C++ to detect such dynamic initialisers.
1702 
</P>
1703 
<P>
1704 
In older dialects of C it was not possible to initialise an automatic
1705 
variable of structure or union type.  This can be checked for using
1706 
the directive:
1707 
<PRE>
1708 
	#pragma TenDRA initialization of struct/union (auto) <I>allow</I>
1709 
</PRE>
1710 
</P>
1711 
<P>
1712 
The directive:
1713 
<PRE>
1714 
	#pragma TenDRA++ complete initialization analysis <I>on</I>
1715 
</PRE>
1716 
can be used to check aggregate initialisers.  The initialiser should
1717 
be fully bracketed (i.e. with no elision of braces), and should have
1718 
an entry for each member of the structure or array.
1719 
</P>
1720 
 
1721 
<HR>
1722 
<H3><A NAME="lvalue">2.2.38. Lvalue expressions</A></H3>
1723 
<P>
1724 
C++ defines the results of several operations to be lvalues, whereas
1725 
they are rvalues in C.  The directive:
1726 
<PRE>
1727 
	#pragma TenDRA conditional lvalue <I>allow</I>
1728 
</PRE>
1729 
is used to apply the C++ rules for lvalues in conditional (<CODE>?:</CODE>)
1730 
expressions.
1731 
</P>
1732 
<P>
1733 
Older dialects of C++ allowed <CODE>this</CODE> to be treated as an
1734 
lvalue. It is possible to enable support for this dialect feature
1735 
using the directive:
1736 
<PRE>
1737 
	#pragma TenDRA++ this lvalue <I>allow</I>
1738 
</PRE>
1739 
however it is recommended that programs using this feature should
1740 
be modified.
1741 
</P>
1742 
 
1743 
<HR>
1744 
<H3><A NAME="discard">2.2.39. Discarded expressions</A></H3>
1745 
<P>
1746 
The directive:
1747 
<PRE>
1748 
	#pragma TenDRA discard analysis <I>on</I>
1749 
</PRE>
1750 
can be used to enable a check for values which are calculated but
1751 
not used.  There are three checks controlled by this directive, each
1752 
of which can be controlled independently.  The directive:
1753 
<PRE>
1754 
	#pragma TenDRA discard analysis (function return) <I>on</I>
1755 
</PRE>
1756 
checks for functions which return a value which is not used.  The
1757 
check needs to be enabled for both the declaration and the call of
1758 
the function in order for a discarded function return to be reported.
1759 
Discarded returns for overloaded operator functions are never reported.
1760 
The directive:
1761 
<PRE>
1762 
	#pragma TenDRA discard analysis (value) <I>on</I>
1763 
</PRE>
1764 
checks for other expressions which are not used.  Finally, the directive:
1765 
<PRE>
1766 
	#pragma TenDRA discard analysis (static) <I>on</I>
1767 
</PRE>
1768 
checks for variables with internal linkage which are defined but not
1769 
used.
1770 
</P>
1771 
<P>
1772 
An unused function return or other expression can be asserted to be
1773 
deliberately discarded by explicitly casting it to <CODE>void</CODE>
1774 
or, equivalently, preceding it by a keyword introduced using the directive:
1775 
<PRE>
1776 
	#pragma TenDRA keyword <I>identifier</I> for discard value
1777 
</PRE>
1778 
A static variable can be asserted to be deliberately unused by including
1779 
it in list of identifiers in a directive of the form:
1780 
<PRE>
1781 
	#pragma TenDRA suspend static <I>identifier-list</I>
1782 
</PRE>
1783 
</P>
1784 
 
1785 
<HR>
1786 
<H3><A NAME="if">2.2.40. Conditional and iteration statements</A></H3>
1787 
<P>
1788 
The directive:
1789 
<PRE>
1790 
	#pragma TenDRA const conditional <I>allow</I>
1791 
</PRE>
1792 
can be used to enable a check for constant expressions used in conditional
1793 
contexts.  A literal constant is allowed in the condition of a <CODE>while
1794 
</CODE>, <CODE>for</CODE> or <CODE>do</CODE> statement to allow for
1795 
such common constructs as:
1796 
<PRE>
1797 
	while ( true ) {
1798 
	    // while statement body
1799 
	}
1800 
</PRE>
1801 
and target dependent constant expressions are allowed in the condition
1802 
of an <CODE>if</CODE> statement, but otherwise constant conditions
1803 
are reported according to the status of this check.
1804 
</P>
1805 
<P>
1806 
The common error of writing <CODE>=</CODE> rather than <CODE>==</CODE>
1807 
in conditions can be detected using the directive:
1808 
<PRE>
1809 
	#pragma TenDRA assignment as bool <I>allow</I>
1810 
</PRE>
1811 
which can be used to disallow such assignment expressions in contexts
1812 
where a boolean is expected.  The error message can be suppressed
1813 
by enclosing the assignment within parentheses.
1814 
</P>
1815 
<P>
1816 
Another common error associated with iteration statements, particularly
1817 
with certain <A HREF="style.html">heretical</A> brace styles, is the
1818 
accidental insertion of an extra semicolon as in:
1819 
<PRE>
1820 
	for ( init ; cond ; step ) ;
1821 
	{
1822 
	    // for statement body
1823 
	}
1824 
</PRE>
1825 
The directive:
1826 
<PRE>
1827 
	#pragma TenDRA extra ; after conditional <I>allow</I>
1828 
</PRE>
1829 
can be used to enable a check for such suspicious empty iteration
1830 
statement bodies (it actually checks for <CODE>;{</CODE>).
1831 
</P>
1832 
 
1833 
<HR>
1834 
<H3><A NAME="switch">2.2.41. Switch statements</A></H3>
1835 
<P>
1836 
A <CODE>switch</CODE> statement is said to be exhaustive if its control
1837 
statement is guaranteed to take one of the values of its
1838 
<CODE>case</CODE> labels, or if it has a <CODE>default</CODE> label.
1839 
The TenDRA C and C++ producers allow a <CODE>switch</CODE> statement
1840 
to be asserted to be exhaustive using the syntax:
1841 
<PRE>
1842 
	switch ( cond ) EXHAUSTIVE {
1843 
	    // switch statement body
1844 
	}
1845 
</PRE>
1846 
where <CODE>EXHAUSTIVE</CODE> is either the directive:
1847 
<PRE>
1848 
	#pragma TenDRA exhaustive
1849 
</PRE>
1850 
or a keyword introduced using:
1851 
<PRE>
1852 
	#pragma TenDRA keyword <I>identifier</I> for exhaustive
1853 
</PRE>
1854 
Knowing whether a <CODE>switch</CODE> statement is exhaustive or not
1855 
means that checks relying on flow analysis (including variable usage
1856 
checks) can be applied more precisely.
1857 
</P>
1858 
<P>
1859 
In certain circumstances it is possible to deduce whether a
1860 
<CODE>switch</CODE> statement is exhaustive or not.  For example,
1861 
the directive:
1862 
<PRE>
1863 
	#pragma TenDRA enum switch analysis <I>on</I>
1864 
</PRE>
1865 
enables a check on <CODE>switch</CODE> statements on values of enumeration
1866 
type.  Such statements should be exhaustive, either explicitly by
1867 
using the <CODE>EXHAUSTIVE</CODE> keyword or declaring a
1868 
<CODE>default</CODE> label, or implicitly by having a <CODE>case</CODE>
1869 
label for each enumerator.  Conversely, the value of each <CODE>case</CODE>
1870 
label should equal the value of an enumerator.  For the purposes of
1871 
this check, boolean values are treated as if they were declared using
1872 
an enumeration type of the form:
1873 
<PRE>
1874 
	enum bool { false = 0, true = 1 } ;
1875 
</PRE>
1876 
</P>
1877 
<P>
1878 
A common source of errors in <CODE>switch</CODE> statements is the
1879 
fall-through from one <CODE>case</CODE> or <CODE>default</CODE>
1880 
statement to the next.  A check for this can be enabled using:
1881 
<PRE>
1882 
	#pragma TenDRA fall into case <I>allow</I>
1883 
</PRE>
1884 
<CODE>case</CODE> or <CODE>default</CODE> labels where fall-through
1885 
from the previous statement is intentional can be marked by preceding
1886 
them by a keyword, <CODE>FALL_THRU</CODE> say, introduced using the
1887 
directive:
1888 
<PRE>
1889 
	#pragma TenDRA keyword <I>identifier</I> for fall into case
1890 
</PRE>
1891 
</P>
1892 
 
1893 
<HR>
1894 
<H3><A NAME="for">2.2.42. For statements</A></H3>
1895 
<P>
1896 
In ISO C++ the scope of a variable declared in a for-init-statement
1897 
is the body of the <CODE>for</CODE> statement; in older dialects it
1898 
extended to the end of the enclosing block.  So:
1899 
<PRE>
1900 
	for ( int i = 0 ; i &lt; 10 ; i++ ) {
1901 
	    // for statement body
1902 
	}
1903 
	return i ;	// OK in older dialects, error in ISO C++
1904 
</PRE>
1905 
This behaviour is controlled by the directive:
1906 
<PRE>
1907 
	#pragma TenDRA++ for initialization block <I>on</I>
1908 
</PRE>
1909 
a state of <CODE>on</CODE> corresponding to the ISO rules and
1910 
<CODE>off</CODE> to the older rules.  Perhaps most useful is the
1911 
<CODE>warning</CODE> state which implements the old rules but gives
1912 
a warning if a variable declared in a for-init-statement is used outside
1913 
the corresponding <CODE>for</CODE> statement body.  A program which
1914 
does not give such warnings should compile correctly under either
1915 
set of rules.
1916 
</P>
1917 
 
1918 
<HR>
1919 
<H3><A NAME="return">2.2.43. Return statements</A></H3>
1920 
<P>
1921 
In C, but not in C++, it is possible to have a <CODE>return</CODE>
1922 
statement without an expression in a function which does not return
1923 
<CODE>void</CODE>.  It is possible to enable this behaviour using
1924 
the directive:
1925 
<PRE>
1926 
	#pragma TenDRA incompatible void return <I>allow</I>
1927 
</PRE>
1928 
Note that this check includes the implicit <CODE>return</CODE> caused
1929 
by falling off the end of a function.  The effect of such a
1930 
<CODE>return</CODE> statement is undefined.  The C++ rule that falling
1931 
off the end of <CODE>main</CODE> is equivalent to returning a value
1932 
of 0 overrides this check.
1933 
</P>
1934 
 
1935 
<HR>
1936 
<H3><A NAME="reach">2.2.44. Unreached code analysis</A></H3>
1937 
<P>
1938 
The directive:
1939 
<PRE>
1940 
	#pragma TenDRA unreachable code <I>allow</I>
1941 
</PRE>
1942 
enables a flow analysis check to detect unreachable code.  It is possible
1943 
to assert that a statement is reached or not reached by preceding
1944 
it by a keyword introduced by one of the directives:
1945 
<PRE>
1946 
	#pragma TenDRA keyword <I>identifier</I> for set reachable
1947 
	#pragma TenDRA keyword <I>identifier</I> for set unreachable
1948 
</PRE>
1949 
</P>
1950 
<P>
1951 
The fact that certain functions, such as <CODE>exit</CODE>, do not
1952 
return a value can be exploited in the flow analysis routines.  The
1953 
equivalent directives:
1954 
<PRE>
1955 
	#pragma TenDRA bottom <I>identifier</I>
1956 
	#pragma TenDRA++ type <I>identifier</I> for bottom
1957 
</PRE>
1958 
can be used to introduce a <CODE>typedef</CODE> declaration for the
1959 
type, bottom, returned by such functions.  The TenDRA API headers
1960 
declare
1961 
<CODE>exit</CODE> and similar functions in this way, for example:
1962 
<PRE>
1963 
	#pragma TenDRA bottom __bottom
1964 
	__bottom exit ( int ) ;
1965 
	__bottom abort ( void ) ;
1966 
</PRE>
1967 
The bottom type is compatible with <CODE>void</CODE> in function declarations
1968 
to allow such functions to be redeclared in their conventional form.
1969 
</P>
1970 
 
1971 
<HR>
1972 
<H3><A NAME="variable">2.2.45. Variable flow analysis</A></H3>
1973 
<P>
1974 
The directive:
1975 
<PRE>
1976 
	#pragma TenDRA variable analysis <I>on</I>
1977 
</PRE>
1978 
enables checks on the uses of automatic variables and function parameters.
1979 
These checks detect:
1980 
<OL>
1981 
<LI>If a variable is not used in its scope.
1982 
<LI>If the value of a variable is used before it has been assigned
1983 
to.
1984 
<LI>If a variable is assigned to twice without an intervening use.
1985 
<LI>If a variable is assigned to twice without an intervening sequence
1986 
point.
1987 
</OL>
1988 
as illustrated by the variables <CODE>a</CODE>, <CODE>b</CODE>,
1989 
<CODE>c</CODE> and <CODE>d</CODE> respectively in:
1990 
<PRE>
1991 
	void f ()
1992 
	{
1993 
	    int a ;			// a never used
1994 
	    int b ;
1995 
	    int c = b ;			// b not initialised
1996 
	    c = 0 ;			// c assigned to twice
1997 
	    int d = 0 ;
1998 
	    d = ++d ;			// d assigned to twice
1999 
	}
2000 
</PRE>
2001 
The second, and more particularly the third, of these checks requires
2002 
some fairly sophisticated flow analysis, so any hints which can be
2003 
picked up from <A HREF="#switch">exhaustive <CODE>switch</CODE>
2004 
statements</A> etc. is likely to increase the accuracy of the errors
2005 
detected.
2006 
</P>
2007 
<P>
2008 
In a non-static member function the various non-static data members
2009 
are analysed as if they were automatic variables.  It is checked that
2010 
each member is initialised in a constructor.  A common source of initialisation
2011 
problems in a constructor is that the base classes and members are
2012 
initialised in the canonical order of virtual bases, non-virtual direct
2013 
bases and members in the order of their declaration, rather than in
2014 
the order in which their initialisers appear in the constructor definition.
2015 
Therefore a check that the initialisers appear in the canonical order
2016 
is also applied.
2017 
</P>
2018 
<P>
2019 
It is possible to change the state of a variable during the variable
2020 
analysis using the directives:
2021 
<PRE>
2022 
	#pragma TenDRA set <I>expression</I>
2023 
	#pragma TenDRA discard <I>expression</I>
2024 
</PRE>
2025 
The first asserts that the variable given by the <I>expression</I>
2026 
has been assigned to; the second asserts that the variable is not
2027 
used.  An alternative way of expressing this is by means of keywords:
2028 
<PRE>
2029 
	SET ( <I>expression</I> )
2030 
	DISCARD ( <I>expression</I> )
2031 
</PRE>
2032 
introduced using the directives.
2033 
<PRE>
2034 
	#pragma TenDRA keyword <I>identifier</I> for set
2035 
	#pragma TenDRA keyword <I>identifier</I> for discard variable
2036 
</PRE>
2037 
respectively.  These expressions can appear in expression statements
2038 
and as the first argument of a comma expression.
2039 
</P>
2040 
<P>
2041 
<IMG SRC="../images/warn.gif" ALT="warning">
2042 
The variable flow analysis checks have not yet been completely implemented.
2043 
They may not detect errors in certain circumstances and for extremely
2044 
convoluted code may occasionally give incorrect errors.
2045 
</P>
2046 
 
2047 
<HR>
2048 
<H3><A NAME="hide">2.2.46. Variable hiding</A></H3>
2049 
<P>
2050 
The directive:
2051 
<PRE>
2052 
	#pragma TenDRA variable hiding analysis <I>on</I>
2053 
</PRE>
2054 
can be used to enable a check for hiding of other variables and, in
2055 
member functions, data members, by local variable declarations.
2056 
</P>
2057 
 
2058 
<HR>
2059 
<H3><A NAME="exception">2.2.47. Exception analysis</A></H3>
2060 
<P>
2061 
The ISO C++ rules do not require exception specifications to be checked
2062 
statically.  This is to facilitate the integration of large systems
2063 
where a single change in an exception specification could have ramifications
2064 
throughout the system.  However it is often useful to apply such checks,
2065 
which can be enabled using the directive:
2066 
<PRE>
2067 
	#pragma TenDRA++ throw analysis <I>on</I>
2068 
</PRE>
2069 
This detects any potentially uncaught exceptions and other exception
2070 
problems.  In the error messages arising from this check, an uncaught
2071 
exception of type <CODE>...</CODE> means that an uncaught exception
2072 
of an unknown type (arising, for example, from a function without
2073 
an exception specification) may be thrown.  For example:
2074 
<PRE>
2075 
	void f ( int ) throw ( int ) ;
2076 
	void g ( int ) throw ( long ) ;
2077 
	void h ( int ) ;
2078 
 
2079 
	void e () throw ( int )
2080 
	{
2081 
	    f ( 1 ) ;			// OK
2082 
	    g ( 2 ) ;			// uncaught 'long' exception
2083 
	    h ( 3 ) ;			// uncaught '...' exception
2084 
	}
2085 
</PRE>
2086 
</P>
2087 
 
2088 
<HR>
2089 
<H3><A NAME="template">2.2.48. Template compilation</A></H3>
2090 
<P>
2091 
The C++ producer makes the distinction between exported templates,
2092 
which may be used in one module and defined in another, and non-exported
2093 
templates, which must be defined in every module in which they are
2094 
used. As in the ISO C++ standard, the <CODE>export</CODE> keyword
2095 
is used to distinguish between the two cases.  In the past, different
2096 
compilers have had different template compilation models; either all
2097 
templates were exported or no templates were exported.  The latter
2098 
is easily emulated - if the <CODE>export</CODE> keyword is not used
2099 
then no templates will be exported.  To emulate the former behaviour
2100 
the directive:
2101 
<PRE>
2102 
	#pragma TenDRA++ implicit export template <I>on</I>
2103 
</PRE>
2104 
can be used to treat all templates as if they had been declared using
2105 
the <CODE>export</CODE> keyword.
2106 
</P>
2107 
<P>
2108 
<IMG SRC="../images/warn.gif" ALT="warning">
2109 
The automatic instantiation of exported templates has not yet been
2110 
implemented correctly.  It is intended that such instantiations will
2111 
be generated during <A HREF="link.html">intermodule analysis</A>
2112 
(where they conceptually belong).  At present it is necessary to work
2113 
round this using explicit instantiations.
2114 
</P>
2115 
 
2116 
<HR>
2117 
<H3><A NAME="catch_all">2.2.49. Other checks</A></H3>
2118 
<P>
2119 
Several checks of varying utility have been implemented in the C++
2120 
producer but do not as yet have individual directives controlling
2121 
their use.  These can be enabled <I>en masse</I> using the directive:
2122 
<PRE>
2123 
	#pragma TenDRA++ catch all <I>allow</I>
2124 
</PRE>
2125 
It is intended that this directive will be phased out as these checks
2126 
are assigned controlling directives.  It is possible to achieve finer
2127 
control over these checks by enabling their individual error messages
2128 
<A HREF="#low">as described above</A>.
2129 
</P>
2130 
 
2131 
<HR>
2132 
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
2133 
Copyright &copy; 1998.</I></P>
2134 
</BODY>
2135 
</HTML>