Ethereal-dev: Re: [Ethereal-dev] 0.9.4: Invalid trailing comma and semicolon

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 30 May 2002 12:01:59 -0700
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.