[splint-discuss] Parse Error on Macro, help

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Sep 7 01:53:10 EDT 2006


James Dennett <jdennett at acm.org> wrote:
	This is the question at hand: was it a change, or was it not?

The WG154 archive definitely SAYS it was.
Terry Colligan <terry-splint at tenberry.com>
also says it was.

	>     #define foobar(dummy) (1+1)
	>     ...
	> 	dummy()
	>
	> would have been legal.
	>   
	Was that the example you meant to use?

OK so there is a silly thinko:  dummy() should have been foobar().

	Did you mean to attempt to use the macro foobar with no
	arguments (which is illegal, as the number of arguments is
	required to match the number of parameters)?

With the correct call, foobar(), you are mistaken.
The number of actual parameters is *ONE*; that parameter happens
to be empty.  This is in no way different from

    #define foo(bar, ugh) bar ugh

    foo(,);		/* two empty arguments */
    foo(,zip());	/* one empty argument */
    foo(zap(),);	/* one empty argument */

	No.  In C90, it was legal to have an empty list of arguments,
	but in C99 it is also legal to have a non-empty list of
	arguments, one or more of which is itself empty.  (C90 does not
	permit an argument to be empty.)

Yes, that's what *I* said.
It's PRECISELY what I said.

	> (A) is a statement that "the latter" (that is, an INVOCATION of a macro
	> with an empty argument) conformed.
	> (B) is a statement that it didn't (it used to be a "common extension",
	> like three-argument main(), not "part of the standard").
	>   
	No; B refers to something else, which is the new feature in C99 of allowing
	#define binary(a,b)
	binary(2,)
	i.e., where there are two arguments but the second argument is empty.

Yes, that's what I *SAID* it was.
Please read more carefully.

	There are probably other lists for language wars.  I use both C
	and C++ as appropriate, and don't find either standard
	particularly more or less readable than the other.

That wasn't a "language war" remark.  It was a remark about the
readability of the *standard*.  Some parts of the C++ standard are good.
But having sweated over the scope rules section for hour after hour,
there is no way that you can persuade me that it is readable.

	Possibly you have misread B to be a contradiction to A, instead of 
	realizing that it must have been referring to empty arguments and not to 
	an empty argument _list_.

You are making me very cross indeed.
I understood PERFECTLY WELL what (B) was referring to.
Please do not assume that someone who disagrees with you is an idiot.

One more time:
	> 	> unless you mean to invoke it as
	> 	>     ... FOO() ...
	> 	
	> 	  Yes! Exactly.
	> 	
	> 	> and the latter really was undefined behaviour caught by at least one
	> 	> compiler.
	> 	
	> (A)	  Then that compiler was not conforming to the 1989 standard.

Got that?
At that point in the mesage, I was talking about *EMPTY ACTUAL ARGUMENTS*
for macros.  Look again and you will see that FOO() is not a macro definition!
I said that passing empty actual arguments ("the latter") was undefined
behaviour caught by a compiler, and (A) is a claim that a compiler that
rejected *EMPTY ACTUAL ARGUMENTS* did not conform to the 1989 standard.

	> (B)	  What C99 upgraded from a common extension to part of the standard was
	> 	  the possiblility of empty actual arguments.

(B) is an explicit statement that EMPTY ACTUAL ARGUMENTS were something
"upgraded" in C99, that they previously were only a "common extension",
not "part of the standard".

That is, (A) and (B) *are* contradictory because they are *BOTH*
about EMPTY ACTUAL ARGUMENTS; *neither* of them is about macro definitions.

	No.  In C90, it was legal to have an empty list of arguments,

which is completely irrelevant to (A) and (B), neither of which is
concerned with macro definitions or their formal parameters.

	I'm very confident that it was not confirmed, and reasonably confident 
	that it is not true.
	
"It" here was "C99 allows EMPTY ACTUAL ARGUMENTS in a macro call and C89
did not".  That _is_ true, and Terry Colligan did confirm it.



More information about the splint-discuss mailing list