This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Postpone __LINE__ evaluation to the end of #line directives
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Max Woodbury <mtewoodbury at gmail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 28 Nov 2013 16:34:10 +0000
- Subject: Re: [PATCH] Postpone __LINE__ evaluation to the end of #line directives
- Authentication-results: sourceware.org; auth=none
- References: <1385548162-1883-1-git-send-email-mtewoodbury at gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311272102530 dot 5433 at digraph dot polyomino dot org dot uk> <5296BDC7 dot 4070101 at gmail dot com>
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 (220.127.116.11) 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
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