preprocessor bug(?)

[Dale Johannesen]

On Thursday, November 7, 2002, at 05:26  PM, Zack Weinberg wrote:

> On Thu, Nov 07, 2002 at 04:46:39PM -0800, Dale Johannesen wrote:
>>>     If there is white space between a backslash and the end of a 
>>> line,
>>>     that is still a continued line.  However, as this is usually the
>>>     result of an editing mistake, and many compilers will not accept
>>>     it as a continued line, GCC will warn you about it.
>>>
>>> Note especially the last paragraph.  The user did get a warning,
>>> didn't they?
>>
>> No.
>
> No, they didn't get a warning?  That is indeed a bug.

No, they didn't get a warning, and neither do I.

>> I understand this is a feature in the case where the \<space> is not
>> inside a comment, and I think it's a useful one.  But I believe the
>> behavior described above violates the standards in this case.
>> Translation phase 2 is not supposed to replace \<space>, and the //
>> comment eats all characters (not tokens) up to the end of the line.
>> It looks to me like the program above is standard-conforming and gcc
>> miscompiles it.
>
> The theory is that in translation phase 1 ("Physical source file
> multibyte characters are mapped, in an implementation-defined manner,
> to the source character set (introducing new-lines for end-of-line
> indicators) if necessary") all trailing whitespace is stripped from
> the input.  It happens that the only way this can affect the meaning
> of a program (now that multiline strings are gone) is when trailing
> whitespace comes between a backslash and the end of a line.
>
> Since \-newline is deleted in translation phase 2, and comment
> processing happens only in phase 3, it would be inconsistent for this
> feature to apply only outside of comments.

I see, thanks.  This does appear to be permitted by the definition of
end-of-line.  It is not very friendly inside a comment, but I see your
point about consistency.