The ISO C99 and C11 standards say in 5.1.1.2#2: "A source file that is not empty shall end in a new-line character". But the following doesn't generate any warning or error message: $ printf 'int main(void) { return 0; }' | gcc -xc -std=c99 -pedantic - $ with all the GCC versions I could test, including a 8.0.0 snapshot [trunk revision 250749]. Clang generates a warning (implied by -pedantic) as expected: $ printf 'int main(void) { return 0; }' | clang-4.0 -xc -std=c99 -pedantic - <stdin>:1:29: warning: no newline at end of file [-Wnewline-eof] int main(void) { return 0; } ^ 1 warning generated. $ GCC should do the same thing and use the same warning name -Wnewline-eof. Note: This bug is apparently a consequence of the fix of PR14331. In the bug report, it was asked for a new option, but the warning was suppressed unconditionally: https://gcc.gnu.org/viewcvs/gcc/trunk/libcpp/lex.c?r1=125212&r2=125211&pathrev=125212
IIRC There was some discussion before and it was decided that the warning was not needed.
See the thread starting at https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html .
https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00504.html See that reasoning there.
(In reply to Andrew Pinski from comment #3) > https://gcc.gnu.org/ml/gcc-patches/2007-04/msg00504.html > > See that reasoning there. "It's really not undefined at all. gcc would be still be standard conformant if we defined all input to end with a newline, whether or not the actual physical Unix input file did so." OK, but this needs to be documented. The GCC manual says: ------------------------------------------------------------------------ 4.2 Environment =============== The behavior of most of these points are dependent on the implementation of the C library, and are not defined by GCC itself. * 'The mapping between physical source file multibyte characters and the source character set in translation phase 1 (C90, C99 and C11 5.1.1.2).' ------------------------------------------------------------------------ However, the fact that all input files are regarded to end with a newline is completely specific to GCC, not part of how the C library works.
Also see http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt ERN 76
(In reply to Andrew Pinski from comment #5) > Also see http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt > ERN 76 This is not about the missing newline at the end of a file. Moreover, GCC doesn't seem to be consistent: $ printf 'int main(void) { return 0; } \\' | gcc -xc -std=c99 - && echo OK <stdin>:1:30: error: stray ‘\’ in program $ printf 'int main(void) { return 0; } \\\n' | gcc -xc -std=c99 - && echo OK <stdin>:1:30: warning: backslash-newline at end of file OK $
And with only the preprocessor: $ printf 'int main(void) { return 0; } \\' | gcc -E - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 31 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "<command-line>" 2 # 1 "<stdin>" int main(void) { return 0; } \ $ printf 'int main(void) { return 0; } \\\n' | gcc -E - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 31 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "<command-line>" 2 # 1 "<stdin>" <stdin>:1:30: warning: backslash-newline at end of file int main(void) { return 0; } $ Here one gets two different results!
(In reply to Vincent Lefèvre from comment #7) > Here one gets two different results! For this latest issue (which is the cause of the error in C), I've reported PR81746.
Changed back to INVALID (there's a bug in bugzilla, which changes INVALID to FIXED after a reload + a new comment).
(In reply to Vincent Lefèvre from comment #9) > Changed back to INVALID (there's a bug in bugzilla, which changes INVALID to > FIXED after a reload + a new comment). Sounds like something your browser did, bugzilla doesn't do that.
C99 seems to explicitly say, within Clause J.2, in the second bullet point: > >1 The behavior is undefined in the following circumstances: > > [...] > A nonempty source file does not end in a new-line character which is not >immediately preceded by a backslash character or ends in a partial >preprocessing token or comment (5.1.1.2). Came across this because Clang has this warning for -pedantic but GCC doesn't.
(In reply to Sam James from comment #11) > C99 seems to explicitly say, within Clause J.2, in the second bullet point: This seems to be in C23 still.
(In reply to Sam James from comment #11) > Came across this because Clang has this warning for -pedantic but GCC > doesn't. GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR 14331 and PR 68994. https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html is the specific one about GCC's behavior and since it is considered undefined at compile time (not a runtime one) GCC behavior is correct so is clang
(In reply to Andrew Pinski from comment #13) > GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR > 14331 and PR 68994. No, PR 14331 was just asking to remove the warning by default, not that `-pedantic` shouldn't warn: "I checked through the gcc manual, and didn't found any option to suppress the warning message "no newline at end of file". And PR 68994 was complaining about the missing warning. > https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html > is the specific one about GCC's behavior and since it is considered > undefined at compile time (not a runtime one) GCC behavior is correct so is > clang Even though GCC decides to add a newline to the logical file, so that the missing diagnostic can be regarded as correct, I think that an optional warning would be useful for portability. https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was suggesting "add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been added?
(In reply to Vincent Lefèvre from comment #14) > Even though GCC decides to add a newline to the logical file, so that the > missing diagnostic can be regarded as correct, I think that an optional > warning would be useful for portability. > https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was > suggesting "add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been > added? Because it was decided the warning was not needed at all so why have an option to turn it on/off if it was not a good warning.
(In reply to Andrew Pinski from comment #15) > (In reply to Vincent Lefèvre from comment #14) > > Even though GCC decides to add a newline to the logical file, so that the > > missing diagnostic can be regarded as correct, I think that an optional > > warning would be useful for portability. > > https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was > > suggesting "add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been > > added? > > Because it was decided the warning was not needed at all so why have an > option to turn it on/off if it was not a good warning. It might not have been *needed*, but some people still might *want* it anyways. I think it's a good warning anyways just for style purposes, even if it isn't strictly necessary.