[Bug preprocessor/20262] New: __LINE__ implementation flaky.

[Bug preprocessor/20262] New: __LINE__ implementation flaky.

[david dot pye at osm dot co dot uk]

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

-- 
           Summary: __LINE__ implementation flaky.
           Product: gcc
           Version: 3.3.5
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: david dot pye at osm dot co dot uk
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

[Bug preprocessor/20262] __LINE__ implementation flaky.

[pinskia at gcc dot gnu dot org]

------- 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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

[Bug preprocessor/20262] __LINE__ implementation flaky.

[neil at daikokuya dot co dot uk]

------- 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.

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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

[Bug preprocessor/20262] __LINE__ implementation flaky.

[neil at daikokuya dot co dot uk]

------- Additional Comments From neil at daikokuya dot co dot uk  2005-03-01 23:36 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

[Bug preprocessor/20262] __LINE__ implementation flaky.

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Indeed, I think the current token could reasonably be anything from 
"assert" to the ")" ending the call to "assert", inclusive.

[Bug preprocessor/20262] __LINE__ implementation flaky.

[gromer at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

Geoff Romer <gromer at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gromer at google dot com

--- Comment #5 from Geoff Romer <gromer at google dot com> ---
The issue isn't the flexibility in "presumed", it's the flexibility in "source
line": the standard defines line number in terms of the "current token", but
gives no explicit guidance about which token is considered "current" in a case
like this, where the preprocessor is arguably expanding two different macros at
the same time.

[Bug preprocessor/20262] __LINE__ implementation flaky.

[aaw at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262

Ollie Wild <aaw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaw at gcc dot gnu.org

--- Comment #4 from Ollie Wild <aaw at gcc dot gnu.org> ---
We recently ran into this issue in a context where __LINE__ was being used to
produce goto labels inside a macro-wrapped block of code.  The code in question
compiled fine with Clang/LLVM but produced a compiler error with GCC.

I've read through the standard (in this case, C++11), and as I read it
"presumed source line" is used to allow for the possibility of modifying the
source line via #line directives (which it says immediately thereafter in a
footnote), not as general consent to be liberal with line numbering. 
Regardless, using the true physical line conforms to the principle of least
surprise.

Would anyone be opposed to revisiting this?