[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What's behind this fix?
From: |
Paul Hilfinger |
Subject: |
Re: What's behind this fix? |
Date: |
Mon, 04 Oct 2010 00:33:55 -0700 |
> > 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