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