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@xxxxxxxxxx> 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
