Re: preprocessor bug(?)

[Dale Johannesen <dalej at apple dot com>]

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.