[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 #24 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:

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

The only uses of the phrase "current line" in C11 are in subclause 5.2.2 
Character display semantics; I suppose you mean "current source line".  
What 6.10.4 says is "The line number of the current source line is one 
greater than the number of new-line characters read or introduced in 
translation phase 1 (5.1.1.2) while processing the source file to the 
current token.", and 6.10.8.1 says __LINE__ expands to "The presumed line 
number (within the current source file) of the current source line (an 
integer constant).".  "line number of the current source line" is defined 
as a whole in terms of the "current token"; "current source line" is not 
something that's defined or meaningful by itself.  Not processing until 
expansion occurs, not processing until the form of a syntax construct is 
identified, but processing to the current token, which is surely __LINE__ 
in this case.

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

Expansion of those tokens is just one instance of macro expansion.  
Exactly the same ambiguity occurs in the case of

#line macro \
( \
__LINE__ \
)

(is "macro", "__LINE__" or ")" the current token?) and does not occur in 
the case of plain

#line __LINE__

> So everyone else is wrong?

Implementations not treating #line __LINE__ as giving the next line the 
same line number as the #line directive are either using a very strained 
interpretation of the standard, or haven't considered the issue and have 
achieved their results by accident.

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

I don't believe the standard makes any such attempt to accommodate such a 
(marginal) need; the wording is simply the most natural way to describe 
the possible forms of #line directive within the style used by the 
standard.  Note there are no examples in the standard to indicate any 
particular intent regarding corner cases of #line or __LINE__.

If you disagree with an implementor (or conformance testsuite vendor, 
etc.) about the interpretation of the standard, the next step is to file a 
DR with WG14.  You can send proposed DRs directly to the convenor - most 
go that way - you don't need to go via your National Body (although WG14 
has no obligation to accept a document as a DR unless the formal NB 
process is followed).