preprocessing directive with no new-line character

[Martin Sebor]

On 07/17/2017 08:15 AM, Vincent Lefevre wrote:
> On 2017-07-17 16:09:42 +0200, Mathieu Malaterre wrote:
>> On Mon, Jul 17, 2017 at 3:19 PM, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
>>> According to the C standard (either C99 or C11), a preprocessing
>>> directive ends with a new-line character: "The last token in the
>>> sequence is the first new-line character that follows the first
>>> token in the sequence."
>>>
>>> But GCC accepts the following program with -std=c99 -pedantic:
>>>
>>> int main (void)
>>> {
>>>   return 0;
>>> }
>>> #define FOO
>>>
>>> where there is no new-line character after "FOO".
>>>
>>> Is there any reason?
>>
>> Do you have 0x0A at the end of your text file ?
>
> No:
>
> zira:~> hd tst.c
> 00000000  69 6e 74 20 6d 61 69 6e  20 28 76 6f 69 64 29 0a  |int main (void).|
> 00000010  7b 0a 20 20 72 65 74 75  72 6e 20 30 3b 0a 7d 0a  |{.  return 0;.}.|
> 00000020  23 64 65 66 69 6e 65 20  46 4f 4f                 |#define FOO|
> 0000002b
>
> And BTW, Clang behaves as expected:
>
> zira:~> clang-4.0 -std=c99 -pedantic tst.c -o tst
> tst.c:5:12: warning: no newline at end of file [-Wnewline-eof]
> #define FOO
>            ^
> 1 warning generated.
>
> So, I think that's a bug in GCC. Do you agree?

I agree.  C requires non-empty source files to end in an unescaped
new-line character.  POSIX further requires that source files be
text files (and defines the term text file as a file organized
into zero or more lines of at most LINE_MAX characters each).

C++ 11 (and later) has a weaker requirement that makes the above
test case valid.

Martin