On Wed, May 29, 2002 at 11:52:51PM -0400, Ashok Narayanan wrote:
> Just a brief question. Is there a specific compiler that complains
> about these commas and semicolons. Specifically why are they
> syntactically illegal (especially the semicolons)?
Commas:
    ANSI X3.159-1989, "American National Standard for Information
    Systems -- Programming Language -- C" (and, I suspect, the
    corresponding ISO standard) says:
	3.5.2.2 Enumeration Specifiers
	Syntax
		<enum-specifier>:
		    enum <identifier>    { <enumerator-list> }
				     opt
		    enum <identifier>
		<enumerator-list>:
		    <enumerator>
		    <enumerator-list> , <enumerator>
which doesn't seem to leave room for a trailing comma in the list.
Semicolons:
    ANSI C also says:
	3.7 External Definitions
	Syntax
		<translation-unit>:
		    <external-declaration>
		    <translation-unit> <external-declaration>
		<external-declaration>:
		    <function-definition>
		    <declaration>
			...
	3.7.2 Function Definitions
	Syntax
		<function-definition>:
		    <declaration-specifiers>    <declarator>
					    opt
			<declaration-list>    <compound-statement>
					  opt
    and
	3.6.2 Compound Statement, or Block
	Syntax
		<compound-statement>:
		    { <declaration-list>    <statement-list>    }
					opt		    opt
which seems to indicate that
	int
	foo(int a)
	{
	};
would be a <function-definition> followed by a semicolon; a semicolon
would, I think, be covered by
	3.6.3 Expression and Null Statements
	Syntax
		<expression-statement>:
		    <expression>    ;
				opt
so it'd be a null statement (one lacking the "opt"ional <expression>),
and the syntax doesn't seem to allow that at the top level in a
<translation-unit>.
There may be compilers that let you get away with those syntactical
errors without any message - but there are also compilers that don't,
and compilers that warn you about them, and, given that, by avoiding the
constructs in question, we can allow the compilers in the former
category to compile Ethereal, and have the compilers in the latter
category produce fewer unnecessary warnings, and thus reduce the noise
level, so that warnings about problems that *should* be fixed (and *can*
be fixed, unlike, for example, many warnings that are the fault of OS or
compiler header files), which I consider a Good Thing.