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 (5.1.1.2) 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 jos...@codesourcery.com
