This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Postpone __LINE__ evaluation to the end of #line directives

On Wed, 27 Nov 2013, Max Woodbury wrote:

> There should be a way to change the __FILE__ value without changing the
> line number sequencing.  Whatever that mechanism is, it should NOT
> introduce maintenance problems that involve counting lines of code.

I think that #line is mainly intended for use by code generators that 
generate C code, rather than directly by people writing C programs.  Such 
a code generator can easily manage counting lines of code.

> A little Googeling quickly turns up examples that make it clear that:
>     #line __LINE__ "new__FILE__value"
> is that expected mechanism,

You'll find any number of examples online based on misconceptions about 
the C languages, possibly together with what one particular implementation 
does.  Any recommendation to do things based on an area where the editor 
of the standard has said the ambiguity in the standard is deliberate is 
clearly a bad recommendation.  Recommendations on use of C should be based 
on areas where the standard is clear and implementations agree.

> In other words, if you processed the text in multiple phases the way
> the standard requires, you would not substitute the value for the
> __LINE__ token until after the end of the directive has been seen.
> Thus the problem only arises because this implementation folds the
> translation phases into a single pass over the text and takes an
> improper short-cut as it does so.  The standard explicitly warns
> against this kind of mistake.

The standard itself mixes up the phases.  Recall that the definition of 
line number is "one greater than the number of new-line characters read or 
introduced in translation phase 1 ( while processing the source 
file to the current token" (where "current token" is never defined).  If 
the phases were completely separate, by your reasoning every newline has 
been processed in phase 1 before any of phases 2, 3 or 4 do anything, and 
so all line numbers relate to the end of the file.  There is absolutely 
nothing to say that the newline at the end of the #line directive has been 
read "while processing the source file to the current token" (if __LINE__ 
in the #line directive is the current token) but that the newline after it 
hasn't been read; if anything, the phases imply that all newlines have 
been read.

This case is just as ambiguous as the case of a multi-line macro call, 
where __LINE__ gets expanded somewhere in the macro arguments, and the 
line number can be that of the macro name, or of the closing parenthesis 
of the call, or somewhere in between, and the standard does not make a 
conformance distinction between those choices.

So, I don't think we should make complicated changes to implement one 
particular choice in an area of deliberate ambiguity without direction 
from WG14 to eliminate the ambiguity in the standard.  Instead, we can let 
the choices be whatever is most natural in the implementation.  If you 
believe the standard is defective in not defining certain things, I advise 
filing a DR (or, when next open for revisions, proposing a paper at a 
meeting to change the definition as you think appropriate).

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]