On 11/27/2013 04:10 PM, Joseph S. Myers wrote:
On further consideration, I'm not convinced there's a bug here at all; I
don't think it's sufficiently defined in the standard what the current
token is for the purposes of line numbering when __LINE__ gets expanded to
be able to say that one or the other value in a directive is wrong. As
far as I can tell after checking the reflector email archives, the only
time WG14 considered anything vaguely relevant was C90 DR#173, which
didn't receive a response.
<https://groups.google.com/forum/#!original/comp.std.c/ulBqfulqO_0/P8AzVfP8U5oJ>
is a statement by the standard editor that some cases were deliberately
left ambiguous. So that suggests the bug should be closed as INVALID (but
if you think this case should be fully defined, you could always file a DR
with WG14).
PLEASE think about this a bit more.
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.
A little Googeling quickly turns up examples that make it clear that:
#line __LINE__ "new__FILE__value"
is that expected mechanism,
A little additional thought should make it clear that multi-line
comments should NOT screw up resetting the line number, They are
supposed to be removed in a translation phase before the phase where
directives are identified.
There is also the way the standard defines the two fixed forms for
'#line' first and then allows for <pp-token> substitution for cases
that do not match the prescribed forms as a separate form. All three
forms require that the <end-of-line> be seen before the directive is
processed which means any substitution for __LINE__ should only take
place AFTER the <end-of-line> that ends the directive has been seen.
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.
It looks to me like WG14 tried quite hard to make the expected form
work the way most people expect it to.
So I have STRONG objections to calling the bug report 'INVALID'!
