"No newline at end of file" compiler warning

Question

What is the reason for the following warning in some C++ compilers?

No newline at end of file

Why should I have an empty line at the end of a source/header file?

Solution 1

Think of some of the problems that can occur if there is no newline. According to the ANSI standard the #include of a file at the beginning inserts the file exactly as it is to the front of the file and does not insert the new line after the #include <foo.h> after the contents of the file. So if you include a file with no newline at the end to the parser it will be viewed as if the last line of foo.h is on the same line as the first line of foo.cpp. What if the last line of foo.h was a comment without a new line? Now the first line of foo.cpp is commented out. These are just a couple of examples of the types of problems that can creep up.

---

Just wanted to point any interested parties to James' answer below. While the above answer is still correct for C, the new C++ standard (C++11) has been changed so that this warning should no longer be issued if using C++ and a compiler conforming to C++11.

From C++11 standard via James' post:

A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file (C++11 §2.2/1).

Solution 2

The requirement that every source file end with a non-escaped newline was removed in C++11. The specification now reads:

A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file (C++11 §2.2/1).

A conforming compiler should no longer issue this warning (at least not when compiling in C++11 mode, if the compiler has modes for different revisions of the language specification).

Solution 3

C++03 Standard [2.1.1.2] declares:

... If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, the behavior is undefined.

Solution 4

The answer for the "obedient" is "because the C++03 Standard says the behavior of a program not ending in newline is undefined" (paraphrased).

The answer for the curious is here: http://gcc.gnu.org/ml/gcc/2001-07/msg01120.html.

Solution 5

It isn't referring to a blank line, it's whether the last line (which can have content in it) is terminated with a newline.

Most text editors will put a newline at the end of the last line of a file, so if the last line doesn't have one, there is a risk that the file has been truncated. However, there are valid reasons why you might not want the newline so it is only a warning, not an error.

View more solutions

Comments

[ThiefMaster]

Not really the reason, but it's very annoying if you cat a file and it does not have a trailing newline as the new shell prompt will appear after the last line of the file (i.e. not in column 0)

[bames53]

@ThiefMaster My $PS1 starts with a newline for that very reason. (it's a multi line prompt anyway, containing a bunch of useful info on one line and then nothing but a prompt character on the next so that fairly long commands don't wrap)

[Brandin]

Why should I have an empty line at the end of a source/header file - If a text file contains one\ntwo\nthree\n then it contains three lines, none of which is empty. If a text file contains one\ntwo\nthree then it is not a text file, in the same sense that a sentence without a full stop at the end is not a sentence.

[mxcl]

Of course in practice every compiler adds a new line after the #include. Thankfully.

[Greg Hewgill]

I recall an old version of Microsoft Visual C++ (like 2.x or something) had exactly this problem. It was exacerbated because the IDE editor encouraged this sort of missing-newline behaviour.

[shylent]

Ahh, the beloved "undefined behaviour". When other languages fail, c/c++ behave in "undefined" ways :) That, certainly, is a big part of their charm. And I am not kidding.

[Adam Rosenfield]

That's all well and good for C++; unfortunately, C still says it's UB, even in the latest draft of the upcoming C1X standard.

[James McNellis]

This question is tagged [c++] and not [c].

[Adam Rosenfield]

Even so, it probably should be tagged [c], since many people searching for this warning in C will find their way here.

[TJ Seabrooks]

This is still a good point to add. Adding this up above. Hope you don't mind.

[Puyover]

Compilers may not complain currently, but GitHub actually does.

[mbx]

I can see the "below" answer by James but: "The above answer" in OrderBy what?! Above is the question, as I usually order by votes. Or do you mean your own answer?

[Destructor]

@Thomas: Is this program invokes undefined behavior because it doesn't end with new line. See program here: ideone.com/jswwf9

[supercat]

I suspect the Standard said that programs without the trailing new-line have Undefined Behavior, rather than stating that they were ill-formed, because some compilers would concatenate a non-terminated final line of an included file with the source code text following the #include directive, and some programmers targeting such compilers may have exploited such behavior. Having the Standard leave such things Undefined would allow programs exploiting such quirks to be well-defined on platforms which specify such behavior. Having the Standard mandate a behavior would break such programs.