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

["mtewoodbury at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #23 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #22)
> 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.

If that is what they meant, they would have said something like "the line 
number when the __LINE__ token is seen', but they say 'current line' and 
define 'current line' elsewhere.

> I think the current token is clearly __LINE__ on the #line directive.  

But the standard says 'current line'.  It says nothing about 'current 
token' in this context.

> 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.)
> 
You are arguing about macro expansion again.  Macro expansion is an 
immediate process and, as you pointed out, somewhat ambiguous.  The case 
being argued here is the expansion of <pp-tokens> in directives where their 
expansion is delayed until after the form of the directive has been 
established.

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

So everyone else is wrong?

Realty, you should consider what the users of the language need to be able 
to do.  There is need for an easy way to change __FILE__ without messing 
up the line number sequence.  '#line __LINE__ ...' is fairly obviously that 
mechanism and the extra verbiage in the standard is a fairly obvious 
attempt to accommodate that need.