[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:

> The elaborate description of the different forms of the '#line' (and other) 
> directives makes it clear that <pp-token> expansion is not to take place until 
> after the <end-of-line> for the directive has been seen.  

The question is not when it takes place, it's what the "current token" is 
when it takes place, because "line number" is defined in terms of the 
current token rather than the time of expansion.  I think the current 
token is clearly __LINE__ on the #line directive.  Consider the case where 
there are no more tokens after that directive, just the newline at the end 
of the directive (you can easily construct cases where the value of 
__LINE__ in such a context affects the validity of the program, by 
concatenating it with something else to form what might or might not be a 
macro name) - it's not possible the the current token to be anything on a 
subsequent line, because there aren't any subsequent tokens.  So the 
current token has got to be __LINE__ (or maybe, in the more complicated 
cases I referred to, something else on the #line line).  That's different 
from

macro
(
__LINE__
)

where all of the tokens from "macro" to ")" are involved in expansion at 
the same time and you can argue for any of "macro", "__LINE__" and ")" as 
being the "current token".  (It's also different from the cases where 
backslash-newline appears in the middle of __LINE__ so the question is 
whether "to the current token" means to the start of end of that token.)

> Accepted usage is for '#line __LINE__' to leave the line numbering unchanged.  

It's quite possible there's a common bug among multiple other 
implementations where it does leave the line number unchanged, but I'm now 
tending to that actually being a bug in those implementations rather than 
an ambiguity in the standard.  That is, there is no way in the standard to 
leave the line number unchanged, and no defect, and it might be better to 
wait until a revision process for a new major C standard version is 
underway them submit a proposal for e.g. #line with just a filename and no 
line number (or a #file directive - either would be a reasonable way of 
achieving that goal).