preprocessor bug(?)

[Zack Weinberg]

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.

> 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.

zw