Subversion Repositories tendra.SVN

Rev

Rev 2 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
2 7u83 1 
<!-- Crown Copyright (c) 1998 -->
2 
<HTML>
3 
<HEAD>
4 
<TITLE>C Checker Reference Manual: Dialect Features</TITLE>
5 
</HEAD>
6 
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
7 
<A NAME=S81>
8 
<H1>C Checker Reference Manual</H1>
9 
<H3>January 1998</H3>
10 
<A HREF="tdfc11.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
11 
<A HREF="tdfc9.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
12 
<A HREF="tdfc1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
13 
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
14 
</A>
15 
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
16 
<HR>
17 
<DL>
18 
<DT><A HREF="#S82"><B>7.1 </B> - Introduction</A><DD>
19 
<DT><A HREF="#S83"><B>7.2 </B> - Resolving linkage problems</A><DD>
20 
<DT><A HREF="#S84"><B>7.3 </B> - Identifier linkage</A><DD>
21 
<DT><A HREF="#S85"><B>7.4 </B> - Implicit integer types</A><DD>
22 
<DT><A HREF="#S86"><B>7.5 </B> - Bitfield types</A><DD>
23 
<DT><A HREF="#S87"><B>7.6 </B> - Extra type definitions</A><DD>
24 
<DT><A HREF="#S88"><B>7.7 </B> - Static block level functions</A><DD>
25 
<DT><A HREF="#S89"><B>7.8 </B> - Incomplete array element types</A><DD>
26 
<DT><A HREF="#S90"><B>7.9 </B> - Forward enumeration declarations</A><DD>
27 
<DT><A HREF="#S91"><B>7.10 </B> - Untagged compound types</A><DD>
28 
<DT><A HREF="#S92"><B>7.11 </B> - External volatility</A><DD>
29 
<DT><A HREF="#S93"><B>7.12 </B> - Identifier name length</A><DD>
30 
<DT><A HREF="#S94"><B>7.13 </B> - Ellipsis in function calls</A><DD>
31 
<DT><A HREF="#S95"><B>7.14 </B> - Conditional lvalues</A><DD>
32 
<DT><A HREF="#S96"><B>7.15 </B> - Unifying the tag name space</A><DD>
33 
<DT><A HREF="#S97"><B>7.16 </B> - Initialisation of compound types</A><DD>
34 
<DT><A HREF="#S98"><B>7.17 </B> - Variable initialisation</A><DD>
35 
<DT><A HREF="#S99"><B>7.18 </B> - Escape sequences</A><DD>
36 
<DT><A HREF="#S100"><B>7.19 </B> - $ in identifier names</A><DD>
37 
<DT><A HREF="#S101"><B>7.20 </B> - Writeable string literals</A><DD>
38 
<DT><A HREF="#S102"><B>7.21 </B> - Concatenation of character string
39 
literals and wide character string literals</A><DD>
40 
<DT><A HREF="#S103"><B>7.22 </B> - Nested comments</A><DD>
41 
<DT><A HREF="#S104"><B>7.23 </B> - Empty source files</A><DD>
42 
<DT><A HREF="#S105"><B>7.24 </B> - Extra commas</A><DD>
43 
<DT><A HREF="#S106"><B>7.25 </B> - Extra semicolons</A><DD>
44 
<DT><A HREF="#S107"><B>7.26 </B> - Compatibility with C++ to TDF producer</A>
45 
<DD>
46 
</DL>
47 
 
48 
<HR>
49 
<H1>7  Dialect Features</H1>
50 
<A NAME=S82>
51 
<HR><H2>7.1  Introduction</H2>
52 
This chapter describes the capabilities of the TenDRA C checker for
53 
enforcing the ISO C standard as well as features for detecting areas
54 
left undefined by the standard. It also lists the non-ISO dialect
55 
features supported by the checker in order to provide compatibility
56 
with older versions of C and allow the use of third-party source which
57 
may contain non-standard constructs.<P>
58 
<A NAME=S83>
59 
<HR><H2>7.2  <A NAME=1>Resolving linkage problems</H2>
60 
Often the way that identifier names are resolved can alter the semantics
61 
of a program. For example, in:<P>
62 
<PRE>
63 
	void f () {
64 
		{
65 
			extern void g ();
66 
			g ( 3 );
67 
		}
68 
		g ( 7 );
69 
	}
70 
</PRE>
71 
the external declaration of g is only in scope in the inner block
72 
of f. Thus, at the second call of g, it is not in scope, and so is
73 
inferred to have declaration:<P>
74 
<PRE>
75 
	extern int g ();
76 
</PRE>
77 
(see 3.4). This conflicts with the previous declaration of g which,
78 
although not in scope, has been registered in the external namespace.
79 
The pragma:<P>
80 
<PRE>
81 
	#pragma TenDRA unify external linkage on
82 
</PRE>
83 
modifies the algorithm for resolving external linkage by searching
84 
the external namespace before inferring a declaration. In the example
85 
above, this results in the second use of g being resolved to the previous
86 
external declaration. The <CODE>on</CODE> can be replaced by <CODE>warning
87 
</CODE> to give a warning when such resolutions are detected, or <CODE>off
88 
</CODE> to switch this feature off.<P>
89 
Another linkage problem, which is left undefined in the ISO C standard,
90 
is illustrated by the following program:<P>
91 
<PRE>
92 
	int f () {
93 
		extern int g ();
94 
		return ( g () );
95 
	}
96 
 
97 
	static int g ()
98 
	{
99 
		return ( 0 );
100 
	}
101 
</PRE>
102 
Is the external variable g (the declaration of which would be inferred
103 
if it was omitted) the same as the static variable g? Of course, had
104 
the order of the two functions been reversed, there would be no doubt
105 
that they were, however, in the given case it is undefined. By default,
106 
the linkage is resolved externally, so that the two uses of g are
107 
not identified. However, the checker can be made to resolve its linkage
108 
internally, so that the two uses of g are identified. The resolution
109 
algorithm can be set using:<P>
110 
<PRE>
111 
	#pragma TenDRA linkage resolution : <EM>action</EM>
112 
</PRE>
113 
where <CODE>action</CODE> can be one of:<P>
114 
<OL>
115 
<LI><CODE>(internal) on</CODE><P>
116 
<LI><CODE>(internal) warning</CODE><P>
117 
<LI><CODE>(external) on</CODE><P>
118 
<LI><CODE>(external) warning</CODE><P>
119 
<LI><CODE>off</CODE><P>
120 
</OL>
121 
depending on whether the linkage resolution is internal, external,
122 
or default, and whether a warning message is required. The most useful
123 
behaviour is to issue a warning for all such occurrences (by setting
124 
action to (internal) warning, for example) so that the programmer
125 
can be alerted to clarify what was intended.<P>
126 
<A NAME=S84>
127 
<HR><H2>7.3  <A NAME=5>Identifier linkage</H2>
128 
The ISO C standard, section 6.1.2.2, states that &quot;if, within
129 
a translation unit, an identifier appears with both internal and external
130 
linkage, the behaviour is undefined&quot;. By default, the checker
131 
silently declares the variable with external linkage. The check to
132 
detect variables which are redeclared with incompatible linkage is
133 
controlled using:<P>
134 
<PRE>
135 
	#pragma TenDRA incompatible linkage <EM>permit</EM>
136 
</PRE>
137 
where <EM>permit</EM><CODE> </CODE><EM>may be </EM><CODE>allow</CODE>
138 
(default mode), <CODE>warning</CODE> (warn about incompatible linkage)
139 
or <CODE>disallow</CODE> (raise errors for redeclarations with incompatible
140 
linkage).<P>
141 
<A NAME=S85>
142 
<HR><H2>7.4  <A NAME=7>Implicit integer types</H2>
143 
Older C dialects allow external variables to be specified without
144 
a type, the type int being inferred. Thus, for example:<P>
145 
<PRE>
146 
	a, b;
147 
</PRE>
148 
is equivalent to:<P>
149 
<PRE>
150 
	int a, b;
151 
</PRE>
152 
By default these inferred declarations are not permitted, though tchk's
153 
behaviour can be modified using:<P>
154 
<PRE>
155 
	#pragma TenDRA implicit int type for external declaration <EM>permit</EM>
156 
</PRE>
157 
where <EM>permit</EM> is <CODE>allow</CODE>, <CODE>warning</CODE>
158 
or <CODE>disallow</CODE>.<P>
159 
A more common feature, allowed by the ISO C standard, but considered
160 
bad style by some, is the inference of an int return type for functions
161 
defined in the form:<P>
162 
<PRE>
163 
	f ( int n ) {
164 
		....
165 
	}
166 
</PRE>
167 
the checker's treatment of such functions can be determined using:<P>
168 
<PRE>
169 
	#pragma TenDRA implicit int type for function return <EM>permit
170 
</EM>
171 
</PRE>
172 
where <CODE>permit</CODE> can be <CODE>allow</CODE>, <CODE>warning</CODE>
173 
or <CODE>disallow</CODE>.<P>
174 
<A NAME=S86>
175 
<HR><H2>7.5  <A NAME=9>Bitfield types</H2>
176 
The ISO C standard only allows signed int, unsigned int and their
177 
equivalent types as type specifiers in bitfields. Using the default
178 
checking profile, tchk raises errors for other integral types used
179 
as type specifiers in bitfields.This behaviour may be modified using
180 
the pragma:<P>
181 
<PRE>
182 
	#pragma TenDRA extra int bitfield type <EM>permit</EM>
183 
</PRE>
184 
<CODE>Permit</CODE> is one of <CODE>allow</CODE> (no errors raised),
185 
<CODE>warning</CODE> (allow non-int bitfields through with a warning)
186 
or <CODE>disallow</CODE> (raise errors for non-int bitfields). <P>
187 
If non-int bitfields are allowed, the bitfield is treated as if it
188 
had been declared with an int type of the same signedness as the given
189 
type. The use of the type char as a bitfield type still generally
190 
causes an error, since whether a plain char is treated as signed or
191 
unsigned is implementation-dependent. The pragma:<P>
192 
<PRE>
193 
	#pragma TenDRA character<EM> set-sign</EM>
194 
</PRE>
195 
where <CODE>set-sign</CODE> is <CODE>signed</CODE>, <CODE>unsigned</CODE>
196 
or <CODE>either</CODE>, can be used to specify the signedness of a
197 
plain char bitfield. If <EM>set-sign</EM> is <CODE>signed</CODE> or
198 
<CODE>unsigned</CODE>, the bitfield is treated as though it were declared
199 
signed char or unsigned char respectively. If <EM>set-sign</EM> is
200 
<CODE>either</CODE>, the sign of the bitfield is target-dependent
201 
and the use of a plain char bitfield causes an error.<P>
202 
<A NAME=S87>
203 
<HR><H2>7.6  <A NAME=13>Extra type definitions</H2>
204 
In accordence with the ISO C standard, in default mode tchk does not
205 
allow a type to be defined more than once using a typedef. The pragma:<P>
206 
<PRE>
207 
	#pragma TenDRA extra type definition <EM>permit</EM>
208 
</PRE>
209 
where <CODE>permit</CODE> is <CODE>allow</CODE> (silently accepts
210 
redefinitions, provided they are consistent), <CODE>warning</CODE>
211 
or <CODE>disallow</CODE>.<P>
212 
<A NAME=S88>
213 
<HR><H2>7.7  <A NAME=15>Static block level functions</H2>
214 
The ISO C standard (Section 6.5.1) states that the declaration of
215 
an identifier for a function that has block scope shall have no explicit
216 
storage-class specifier other than extern. By default, tchk raises
217 
an error for declarations which do not conform to this rule. The behaviour
218 
can be modified using:<P>
219 
<PRE>
220 
	#pragma TenDRA block function static <EM>permit</EM>
221 
</PRE>
222 
where <CODE>permit</CODE> is <CODE>allow</CODE> (accept block scope
223 
function declarations with other storage-class specifiers), <CODE>disallow
224 
</CODE> or <CODE>warning</CODE>. <P>
225 
<A NAME=S89>
226 
<HR><H2>7.8  <A NAME=17>Incomplete array element types</H2>
227 
The ISO C standard (Section 6.1.2.5) states that an incomplete type
228 
e.g an undefined structure or union type, is not an object type and
229 
that array elements must be of object type. The default behaviour
230 
of the checker causes errors when incomplete types are used to specify
231 
array element types. The pragma: <P>
232 
<PRE>
233 
	#pragma TenDRA incomplete type as object type <EM>permit</EM>
234 
</PRE>
235 
can be used to alter the treatment of array declarations with incomplete
236 
element types. <EM>Permit</EM> is one of <CODE>allow</CODE>, <CODE>disallow
237 
</CODE> or <CODE>warning</CODE> as usual.<P>
238 
<A NAME=S90>
239 
<HR><H2>7.9  <A NAME=19>Forward enumeration declarations</H2>
240 
The ISO C Standard (Section 6.5.2.3) states that the first introduction
241 
of an enumeration tag shall declare the constants associated with
242 
that tag. This rule is enforced by the checker in default mode, however
243 
it can be relaxed using the pragma: <P>
244 
<PRE>
245 
	#pragma TenDRA forward enum declaration <EM>permit</EM>
246 
</PRE>
247 
where replacing <CODE>permit</CODE> by <CODE>allow</CODE> permits
248 
the declaration and use of an enumeration tag before the declaration
249 
of its associated enumeration constants. A <CODE>disallow</CODE> variant
250 
which restores the default behaviour is also available.<P>
251 
<A NAME=S91>
252 
<HR><H2>7.10  <A NAME=21>Untagged compound types</H2>
253 
The ISO C standard states that a declaration must declare at least
254 
a declarator, a tag or the members of an enumeration. The checker
255 
detects such declarations and, by default, raises an error. The severity
256 
of the errors can be altered by: <P>
257 
<PRE>
258 
	#pragma TenDRA unknown struct/union <EM>permit</EM>
259 
</PRE>
260 
where <CODE>permit</CODE> may be <CODE>allow</CODE> to allows code
261 
such as: <P>
262 
<PRE>
263 
	struct {int i; int j;};
264 
</PRE>
265 
through without errors (statements such as this occur in some system
266 
headers) or <CODE>disallow</CODE> to restore the default behaviour.<P>
267 
<A NAME=S92>
268 
<HR><H2>7.11  <A NAME=23>External volatility</H2>
269 
The inclusion of the pragma: <P>
270 
<PRE>
271 
	        #pragma TenDRA external volatile_t
272 
</PRE>
273 
instructs the checker thereafter to treat any object declared with
274 
external linkage (ISO C standard Section 6.1.2.2) as if it were volatile
275 
(ISO C standard Section 6.5.3). This was a feature of some traditional
276 
C dialects. In the default mode, objects with external linkage are
277 
only treated as volatile if they were declared with the volatile type
278 
qualifier.<P>
279 
<A NAME=S93>
280 
<HR><H2>7.12  <A NAME=25>Identifier name length</H2>
281 
Under the ISO C standard rules on identifier name length, an implementation
282 
is only required to treat the first 31 characters of an internal name
283 
and the first 6 characters of an external name as significant. The
284 
TenDRA C checker provides a facility for users to specify the maximum
285 
number of characters allowed in an identifier name, to prevent unexpected
286 
results when the application is moved to a new implementation. The
287 
limit is set using:<P>
288 
<PRE>
289 
	#pragma TenDRA set name limit <EM>integer_constant</EM>
290 
</PRE>
291 
There is currently no distinction made between external and internal
292 
names for length checking. Identifier name lengths are not checked
293 
in the default mode.<P>
294 
<A NAME=S94>
295 
<HR><H2>7.13  <A NAME=27>Ellipsis in function calls</H2>
296 
An ellipsis is not an identifier and should not be used in a function
297 
call, even if, as in the program below, the function prototype contains
298 
an ellipsis: <P>
299 
<PRE>
300 
	int f(int a,...) {
301 
		return 1; }
302 
	int main() {
303 
		int x, y;
304 
		x=f(y ,...);
305 
		return 1;
306 
	}
307 
</PRE>
308 
In default mode the checker raises an error if an ellipsis is used
309 
as a parameter in a function call. The severity of this error can
310 
be modified by using: <P>
311 
<PRE>
312 
	#pragma TenDRA ident ... <EM>permit</EM>
313 
</PRE>
314 
If <CODE>permit</CODE> is replaced by <CODE>allow</CODE> the ellipsis
315 
is ignored, if <CODE>warning</CODE> is used tchk produces a warning
316 
and if <CODE>disallow</CODE> is used the default behaviour is restored.<P>
317 
<A NAME=S95>
318 
<HR><H2>7.14  <A NAME=29>Conditional lvalues</H2>
319 
The ? operator cannot normally be used to define an lvalue, so that
320 
for example, the program:<P>
321 
<PRE>
322 
	struct s {int a, b; };
323 
	void f (int n,struct s *s1,struct s *s2) {
324 
		( n ? s1: s2)-&gt;a = 0;
325 
	}
326 
</PRE>
327 
is not allowed in ISO C. The pragma:<P>
328 
<PRE>
329 
	#pragma TenDRA conditional lvalue allow
330 
</PRE>
331 
allows conditional lvalues if:<P>
332 
<OL>
333 
<LI>Both options of the conditional operator have compatible compound
334 
types;<P>
335 
<LI>Both options of the conditional are lvalues.<P>
336 
</OL>
337 
(there is also a <CODE>disallow</CODE> variant, but <CODE>warning</CODE>
338 
is not permitted in this case).<P>
339 
<A NAME=S96>
340 
<HR><H2>7.15  <A NAME=31>Unifying the tag name space</H2>
341 
Each object in the tag name space is associated with a classification
342 
(struct, union or enum) of the type to which it refers. If such a
343 
tag is used, it must be preceded by the correct classification, otherwise
344 
the checker produces an error by default. However, the pragma:<P>
345 
<PRE>
346 
	#pragma TenDRA ignore struct/union/enum tag <EM>status</EM>
347 
</PRE>
348 
may be used to change the severity of the error. The options for <EM>status
349 
</EM>are: <CODE>on </CODE>(allows a tag to be used with any of the
350 
three classifications, the correct classification being inferred from
351 
the type definition), <CODE>warning</CODE> or <CODE>off</CODE>.<P>
352 
<A NAME=S97>
353 
<HR><H2>7.16  <A NAME=33>Initialisation of compound types</H2>
354 
Many older C dialects do not allow the initialisation of automatic
355 
variables of compound type. Thus, for example:<P>
356 
<PRE>
357 
	void f () {
358 
		struct {
359 
			int a;
360 
			int b;
361 
		} x = { 3, 2 };
362 
	}
363 
</PRE>
364 
would not be allowed by some older compilers, although by default
365 
tchk does not raise any errors since the code is legal according to
366 
the ISO C standard. The checker's behaviour may be changed using:<P>
367 
<PRE>
368 
	#pragma TenDRA initialization of struct/union (auto) <EM>permit</EM>
369 
</PRE>
370 
where <CODE>permit</CODE> is <CODE>allow</CODE>, <CODE>warning</CODE>
371 
or <CODE>disallow</CODE>. This feature is particularly useful when
372 
developing a program which is intended to be compiled with a compiler
373 
which does not support automatic compound initialisations.<P>
374 
<A NAME=S98>
375 
<HR><H2>7.17  <A NAME=35>Variable initialisation</H2>
376 
The ISO C standard (Section 6.5.7) states that all expressions in
377 
an initialiser for an object that has static storage duration or in
378 
an initialiser-list for an object that has aggregate or union type
379 
shall be constant expressions. The pragma: <P>
380 
<PRE>
381 
	#pragma TenDRA variable initialization <EM>permit</EM>
382 
</PRE>
383 
may be used to allow non-constant initialisers if <EM>permit</EM>
384 
is replaced by <CODE>allow</CODE>. The other option for <EM>permit</EM>
385 
is <CODE>disallow</CODE> which restores the default behaviour of flagging
386 
non-constant initialisers for objects of static storage duration as
387 
errors.<P>
388 
<A NAME=S99>
389 
<HR><H2>7.18  <A NAME=36>Escape sequences</H2>
390 
The ISO C standard specifies a small set of escape sequences in strings,
391 
for example \n as newline. Unknown escape sequences lead to an error
392 
in the default mode , however the severity of the error may be altered
393 
using:<P>
394 
<PRE>
395 
	#pragma TenDRA unknown escape <EM>permit</EM>
396 
</PRE>
397 
where <EM>permit</EM> is <CODE>allow</CODE> (silently replaces the
398 
unknown escape sequence, \z say, by z), <CODE>warning</CODE> or <CODE>disallow
399 
</CODE>.<P>
400 
<A NAME=S100>
401 
<HR><H2>7.19  <A NAME=39>$ in identifier names</H2>
402 
The ISO C standard (Section 6.1) states that the use of the character
403 
$ in identifier names is illegal. The pragma: <P>
404 
<PRE>
405 
	#pragma TenDRA dollar as ident allow
406 
</PRE>
407 
can be used to allow such identifiers, which by default are flagged
408 
as errors. There is also a <CODE>disallow</CODE> variant which restores
409 
the default behaviour. <P>
410 
<A NAME=S101>
411 
<HR><H2>7.20  <A NAME=41>Writeable string literals</H2>
412 
The ISO C standard, section 6.1.4, states that &quot;if the program
413 
attempts to modify a string literal of either form, the behaviour
414 
is undefined&quot;. Assignments to string literals of the form:<P>
415 
<PRE>
416 
	&quot;abc&quot;='3';
417 
</PRE>
418 
always result in errors. Other attempts to modify members of string
419 
literals, e.g.<P>
420 
<PRE>
421 
	&quot;abc&quot;[1]='3';
422 
</PRE>
423 
are permitted in the default checking mode. This behaviour can be
424 
changed using:<P>
425 
<PRE>
426 
	#pragma TenDRA writeable string literal <EM>permit</EM>
427 
</PRE>
428 
where <EM>permit</EM> may be <CODE>allow</CODE>, <CODE>warning</CODE>
429 
or <CODE>disallow</CODE>.<P>
430 
<A NAME=S102>
431 
<HR><H2>7.21  <A NAME=43>Concatenation of character string literals
432 
and wide character string literals</H2>
433 
The ISO C standard, section 6.1.4, states that if a character string
434 
literal is adjacent to a wide character string literal, the behaviour
435 
is undefined. By default, this is flagged as an error by the checker.
436 
If the pragma:<P>
437 
<PRE>
438 
	#pragma TenDRA unify incompatible string literal <EM>permit</EM>
439 
</PRE>
440 
is used, with <EM>permit</EM> set to <CODE>allow</CODE> or <CODE>warning</CODE>
441 
the character string literal is converted to a wide character string
442 
literal and the strings are concatenated, although in the <CODE>warning</CODE>
443 
case a warning is output. <EM>The</EM><CODE> disallow</CODE> version
444 
of the pragma restores the default behaviour.<P>
445 
<A NAME=S103>
446 
<HR><H2>7.22  <A NAME=45>Nested comments</H2>
447 
The occurence of the `/*' characters inside a C comment, i.e. text
448 
surrounded by the `/*' and `*/' symbols, is usually a mistake and
449 
can lead to the termination of a comment unexpectedly. By default
450 
such nested comments are processed silently, however an error or warning
451 
can be produced by setting:<P>
452 
<PRE>
453 
	#pragma TenDRA nested comment analysis <EM>status</EM>
454 
</PRE>
455 
with <EM>status</EM> as <CODE>on</CODE> or <CODE>warning</CODE>. If
456 
<EM>status</EM> is <CODE>off</CODE> the default behaviour is restored.<P>
457 
<A NAME=S104>
458 
<HR><H2>7.23
459 
<A NAME=50>Empty source files</H2>
460 
The ISO standard states that each source file should contain at least
461 
one declaration or definition. Source files which contain no external
462 
declarations or definitions are flagged as errors by the checker in
463 
default mode. The severity of the error may be altered using:<P>
464 
<PRE>
465 
	#pragma TenDRA no external declaration <EM>permit</EM>
466 
</PRE>
467 
where the options for <CODE>permit</CODE> are <CODE>allow</CODE> (no
468 
errors raised), <CODE>warning</CODE> or <CODE>disallow</CODE>.<P>
469 
<A NAME=S105>
470 
<HR><H2>7.24  <A NAME=52>Extra commas</H2>
471 
The ISO C standard does not allow extra commas in enumeration type
472 
declarations e.g. <P>
473 
<PRE>
474 
	enum e = {red, orange, yellow,};
475 
</PRE>
476 
The extra comma at the end of the declaration is flagged as an error
477 
by default, but this behaviour may be changed by using: <P>
478 
<PRE>
479 
	#pragma TenDRA extra , <EM>permit</EM>
480 
</PRE>
481 
where <EM>permit</EM> has the usual <CODE>allow</CODE><EM>,</EM><CODE>
482 
disallow</CODE> and <CODE>warning</CODE> options. <P>
483 
<A NAME=S106>
484 
<HR><H2>7.25  <A NAME=54>Extra semicolons</H2>
485 
Some dialects of C allow extra semicolons at the external declaration
486 
and definition level in contravention of the ISO C standard. For example,
487 
the program:<P>
488 
<PRE>
489 
	int f () {
490 
		return ( 0 );
491 
	};
492 
</PRE>
493 
is not ISO compliant. The checker enforces the ISO rules by default,
494 
but the errors raised may be reduced to warning or suppressed entirely
495 
using:<P>
496 
<PRE>
497 
	#pragma TenDRA extra ; <EM>permit</EM>
498 
</PRE>
499 
with <EM>permit</EM> as <CODE>warning</CODE> or <CODE>allow</CODE>.
500 
The <CODE>disallow</CODE> option restores the default behaviour.<P>
501 
<A NAME=S107>
502 
<HR><H2>7.26  <A NAME=56>Compatibility with C++ to TDF producer</H2>
503 
In the interests of compatibility between the C checker and the new
504 
C++ checker, all pragmas beginning:<P>
505 
<PRE>
506 
	#pragma TenDRA ++
507 
</PRE>
508 
are silently ignored by tchk.<P>
509 
<P>
510 
<!-- FM pgf ignored -->
511 
<HR>
512 
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
513 
Copyright &copy; 1998.</I></P>
514 
</BODY>
515 
</HTML>