Re: [PATCH] Feature request PR14331: add -W(no-)eof-newline

[Ian Lance Taylor <iant at google dot com>]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Well, but what happens if an include file ends with '//', but no newline?
> Does the newline after the #include terminate the comment, or has that already
> been implicitly replaced by the content of the include file and therefore the
> line after the #include gets commented out?  I think this is why the standard
> calls it undefined behaviour: too specific on tiny details of the
> implementation of the parser.  I think someone said upthread that to be fully
> conformant, we have to at least be capable of issuing a diagnostic.
> 
>   That doesn't mean we might not want to default it off and only have it under
> -pedantic - or if explitly requested by Weof-newline :-)

The standard does not specify the mapping between the physical input
file and the logical input file.  It can't because there are too many
variations on different operating systems.

We can define gcc's mapping from the physical input file to the
logical input file to include "if the physical input file does not end
in a newline, add a newline at the end of the logical input file."  By
my reading, that would be fully standard conformant.  No diagnostic is
required.

We already do something quite similar with backslash at the end of a
line.  We define our mapping from the physical file to the logical
file to include discarding all whitespace after a backslash at the end
of a line.  Thus, for gcc
    backslash space newline
will cause the lines to be concatenated in a macro definition.  This
is standard conformant even though the standard only specifies line
concatenation for
    backslash newline

Ian