I checked through the gcc manual, and didn't found any option to suppress the warning message "no newline at end of file". It clutters the error log when I'm compiling a lot of files. Thanks, Alex
Confirmed, note that on some C preprocessors will just error out as this is required by the standard.
If there is a way to encourage this bug to achieve higher priority, I would love to do it. Using GCC and MSVC (and Dev Studio) together, one runs into this one a lot. A -w flag to turn this warning off would be outstanding.
I bet it would be a lot more work to add this flag to gcc than to do something like for i in * ; do echo >> $i ; done on the files for which you get this warning. Adding flags to gcc is complex and has some future maintainance costs, whereas it is really easy to fix this problem in your own sources. W.
I agree with Wolfgang, it's just too easy to fix the source to be worth wasting developer time. Brian, if you feel strongly about it, why don't you just prepare a patch yourself? Adding a flag for a warning and an if() before the warning line isn't that hard.
A patch to gcc-3.3.3 to do exactly what you're asking for was posted by Dave Korn a few months ago, and approved in principle: http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html I'll attach a copy of the patch here.
Created attachment 8456 [details] Dave Korn's patch to add a -Wno-eof-newline option
(In reply to comment #6) > Created an attachment (id=8456) [edit] > Dave Korn's patch to add a -Wno-eof-newline option Dave, This seems like the right patch, could you update it for the changes in options and the preprocessor sources moving? If you don't have time to do it, I can do it.
What is the status of this patch?
In my opinion the patch is too old, now we have other mechanism for handling options, and it lacks documentation updates and testcases. Also, it is a standards conformance warning, so perhaps it should be just moved to -pedantic (if you look at the code, it is already a pedantic warning, it is just enabled all the time). This will avoid adding yet another warning option.
This is just a nuisance at the end of a .c or .cpp file. It is, however, a serious error that should always be notified at the end of an included (header) file.
Tom: The status is "Ooops, completely forgot about that one". (Well, to be fair, it's "Ooops, never even knew about that one as I wasn't on the Cc: list for this bug until I stumbled across it today purely by chance"; Dan Kegel added my patch to this PR, Andrew Pinski thought I was on the Cc list at comment #7 but I wasn't.... so this is the first I know of it!) The issue just came up on the gcc list today, though, so I think I should pick it back up. If I forget again, please feel free to drop me private email to remind me. Manuel: Yes, the patch is against 3.3 series, I didn't actually formally submit it but just posted it to the list when someone was in need of a patch. See http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html Before resubmitting I would /of course/ a) up-port to current mainline b) use the most appropriate of the current options-handling mechanisms and c) add testcases and docs. Can you advise me what you think the best way to add the option is? I particularly think I ought to avoid "manually copying a global in c_common_post_options" (as I wrote at url above).
(In reply to comment #11) > Manuel: Yes, the patch is against 3.3 series, I didn't actually formally > submit it but just posted it to the list when someone was in need of a patch. > See > > http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html > > Before resubmitting I would /of course/ a) up-port to current mainline b) use > the most appropriate of the current options-handling mechanisms and c) add > testcases and docs. Can you advise me what you think the best way to add the > option is? I particularly think I ought to avoid "manually copying a global > in c_common_post_options" (as I wrote at url above). > I was not criticizing your patch. Tom asked and I gave my opinion: that the patch would need to be updated by someone (not necessarily you) before being accepted. To see the proper way to add the option look for endif_labels in c.opt and c-opts.c. Notice that you don't need to define a global option anymore in gcc/flags.h (although it seems that you still need it in libcpp/include/cpplib.h). To keep current behaviour, you need to enable the option by default. If it were a front-end option you would need to enable it in c.opt using Init(1) (see other options in the same file). However, I don't think that setting affects automatically CPP options, so probably you need to set the option in libccp/init.c as you do in your original patch. Of course, you also need to conditionalize the warning on the option, but your patch already does this. I hope this helps.
Manu: "I was not criticizing your patch. [ ... ] " So sorry, I didn't mean you to think I was offended! I took your comment completely at face value. " [ ... ] I hope this helps." It most certainly does! I am testing a revised and updated patch. cheers, DaveK
Patch posted for review at http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html
Subject: Bug number PR14331 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html
Oh, BTW, congratulations Tom on being appointed a libcpp maintainer! <grin-grin-hint-hint-nudge-nudge-wink-wink....>
Subject: Bug number preprocessor/14331 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00399.html
Patch was approved...
Subject: Bug 14331 Author: davek Date: Thu May 31 02:06:48 2007 New Revision: 125212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125212 Log: 2007-05-31 Dave Korn <dave.korn@artimi.com> PR preprocessor/14331 * lex.c (_cpp_get_fresh_line): Don't warn if no newline at EOF. Modified: trunk/libcpp/ChangeLog trunk/libcpp/lex.c
Fixed.
*** Bug 68994 has been marked as a duplicate of this bug. ***