GCC Bugzilla Bug 20262

The following code snippet triggers the assert.

Interestingly, the exact message that you get depends on the gcc version. 2.9x
gives you a "6+1 != 6" message, where 3.x gives you a "7+1 != 7".

On gcc3.3.5:
silly: sillytest.c:7: main: Assertion `((7) + 1 == (7))' failed.
Aborted

The code is as follows.

#include <assert.h>
#define macro(a, b) ((a) + 1 == (b))
int
main(void)
{
       assert(macro(__LINE__
                , __LINE__));
       return 0;
}

You're not alone - the only compiler I've found that does what I expect is the
SunWorkshop Pro compiler. Pretty much all the rest mess up somewhere along the line!

Cheers,

David

Outer Macros are expanded before inner ones and they get all placed on one line
so this is invalid.

Subject: Re:  __LINE__ implementation flaky.

pinskia at gcc dot gnu dot org wrote:-

> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-01 17:16 -------
> Outer Macros are expanded before inner ones and they get all placed on one line so this is invalid.

Huh? This is a bug.

The reason it happens is nothing to do with inner or outer macros,
but the fact that arguments are collected before being expanded,
and an implementation detail where we don't take the line from the
token (otherwise __LINE__ would be misexpanded if the RHS of a
macro definition) but from the global line counter.

It may not be worth fixing; I suspect the reason other implementations
fail too is that it's hard to get it right, and the ability to easily
do so is heavily dependent on exactly how your preprocessor is
implemented.  (a bit like the #s vs %:s bug).

Neil.

Subject: Re:  __LINE__ implementation flaky.

neil at daikokuya dot co dot uk wrote:-

> 
> ------- Additional Comments From neil at daikokuya dot co dot uk  2005-03-01 23:13 -------
> Subject: Re:  __LINE__ implementation flaky.
> 
> pinskia at gcc dot gnu dot org wrote:-
> 
> > 
> > ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-01 17:16 -------
> > Outer Macros are expanded before inner ones and they get all placed on one line so this is invalid.
> 
> Huh? This is a bug.

Actually I take that back - I think you can say that the wording
of the standard is sufficiently vague that this is not a bug, and
may even be correct behaviour.  The standard says that (at the time
of expansion) it's the "presumed current source line of the file".
Since expansion happens after argument collection, it's not hard
to argue that the current source line of the file is constant for
both __LINE__ tokens.

Neil.