Re: What's behind this fix?

[Paul Hilfinger]

 > > Replacing a definition from Flex:
 > > 
 > >   #define gram_wrap(n) 1
 > > 
 > > which is subsequently invoked in the Flex skeleton with 
 > > 
 > >    if ( gram_wrap( ) )
 > > 
 > > I can't for the life of me see anything wrong with the original (Flex's) 
 > > definition of gram_wrap or with its use.  It certainly works on my
 > > version of gcc (3.4.4 on Solaris).  What gives?
 > 
 > It's not portable.  The C Standard says that a macro argument
 > cannot be empty.  In this case the parameter n would be bound
 > to an empty argument.  Most compilers accept this, but some do not
 > (otherwise I'd never have discovered that portability bug).

Is this new?  My copy of ISO 9899:1999 does not seem to imply any such
thing.  Indeed, it says  (6.10.3(4)):

   "If the identifier-list in the macro definition does not end with an
    ellipsis, the number of arguments (including those arguments consisting
    of no preprocessing tokens) in an invocation of a function-like macro
    shall equal the number of parameters in the macro definition. "

which certainly SEEMS to countenance empty arguments.  But then, there
appears to be a glitch in the standard.  It implies that in the function-
like macro invocation

      foo()

there is one (empty) argument, which could NOT then match the 0
arguments allowed by

      #define foo() etc.

So, if the behavior of anything is non-portable, it would seem to be
that of the declaration above, which is not clearly defined ever to
match anything, while I would hold that

      #defien foo(n) etc.

IS clearly defined to match foo().

Paul