If the preprocessor finds a backslash-newline continuation on the next-to-last
line of a file which does not end with a newline (the file, not the next-to-last
line), it gives the warning.
Here's a 2-line file:
#define MYMACRO(x) \
x
and here it is in hex, to show the lack of a final newline:
[EMAIL PROTECTED] tmp]$ od -t x ~/tmp/test.defs
0000000 66656423 20656e69 4d594d20 4f524341
0000020 20297828 20202020 20202020 200a5c20
0000040 20202020 20202020 00000078
0000051
then:
[EMAIL PROTECTED] tmp]$ gcc -v -P -CC -I. -E -x c test.defs
Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --enable-long-long
--enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions
--enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu
--with-system-zlib
Thread model: posix
gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)
/usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/cc1 -E -quiet -CC -v -I. -P
test.defs -mtune=pentium
ignoring nonexistent directory
"/usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/../../../../i586-mandrake-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/include
/usr/include
End of search list.
test.defs:1:30: warning: backslash-newline at end of file
If I add a newline as the last byte of the file, the warning is not given. The
warning is spurious because the backslash-newline is not at the end of the file.
Even if the warning has value in the case where the backslash-newline is
followed only by whitespace, that isn't the case here.
--
Summary: Spurious "backslash-newline at end of file" warning
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ftg at adelphia dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18200
