"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?

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) — ThiefMaster, Nov 20 '11 at 21:12
@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) — bames53, Feb 18 '14 at 18:15
`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. — Brandin, Jun 22 '14 at 08:00

score 228 · Accepted Answer · edited Mar 30 '19 at 03:38

228

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).

edited Mar 30 '19 at 03:38

S.S. Anne

15,171
8
38
76

answered Sep 16 '08 at 13:49

TJ Seabrooks

20,203
6
33
30

30

Of course in practice every compiler adds a new line after the #include. Thankfully. – mxcl Oct 20 '08 at 19:06
3

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. – Greg Hewgill Nov 12 '08 at 03:29
2

Compilers may not complain currently, but GitHub actually does. – Kactung Apr 21 '13 at 01:46
1

I can see the ["below" answer by James](http://stackoverflow.com/a/8172348/303290) but: "The above answer" in OrderBy what?! Above is the question, as I usually order by votes. Or do you mean your own answer? – mbx Feb 11 '14 at 12:38
@Thomas: Is this program invokes undefined behavior because it doesn't end with new line. See program here: http://ideone.com/jswwf9 – Destructor Jul 31 '15 at 07:02

score 49 · Answer 2 · answered Nov 17 '11 at 18:30

49

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).

answered Nov 17 '11 at 18:30

James McNellis

348,265
75
913
977

4

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. – Adam Rosenfield Nov 17 '11 at 18:44
12

This question is tagged [c++] and not [c]. – James McNellis Nov 17 '11 at 18:47
4

Even so, it probably *should* be tagged [c], since many people searching for this warning in C will find their way here. – Adam Rosenfield Nov 18 '11 at 15:27
1

This is still a good point to add. Adding this up above. Hope you don't mind. – TJ Seabrooks Nov 20 '11 at 20:57

score 28 · Answer 3 · edited Aug 06 '15 at 08:57

28

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.

edited Aug 06 '15 at 08:57

Lightness Races in Orbit

378,754
76
643
1,055

answered Sep 16 '08 at 13:52

Igor Semenov

1,548
9
7

score 16 · Answer 4 · edited Aug 06 '15 at 08:57

16

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.

edited Aug 06 '15 at 08:57

Lightness Races in Orbit

378,754
76
643
1,055

answered Sep 16 '08 at 13:46

Vytautas Šaltenis

655
3
15

6

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. – shylent Jan 16 '10 at 21:41

score 6 · Answer 5 · answered Sep 16 '08 at 13:40

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.

score 6 · Answer 6 · edited Dec 22 '15 at 22:59

6

#include will replace its line with the literal contents of the file. If the file does not end with a newline, the line containing the #include that pulled it in will merge with the next line.

edited Dec 22 '15 at 22:59

LogicStuff

19,397
6
54
74

answered Sep 16 '08 at 13:47

moonshadow

86,889
7
82
122

score 3 · Answer 7 · answered Dec 23 '14 at 16:47

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

not specific C/C++ but a C dialect: when using the GL_ARB_shading_language_include extension the glsl compiler on OS X warns you NOT about a missing newline. So you can write a MyHeader.h file with a header guard which ends with #endif // __MY_HEADER_H__ and you will lose the line after the #include "MyHeader.h" for sure.

score 2 · Answer 8 · answered Dec 11 '12 at 09:47

I am using c-free IDE version 5.0,in my progrm either of 'c++' or 'c' language i was getting same problem.Just at the end of the program i.e. last line of the program(after braces of function it may be main or any function),press enter-line no. will be increased by 1.then execute the same program,it will run without error.

score 2 · Answer 9 · answered Aug 06 '15 at 08:43

Because the behavior differs between C/C++ versions if file does not end with new-line. Especially nasty is older C++-versions, fx in C++ 03 the standard says (translation phases):

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, the behavior is undefined.

Undefined behavior is bad: a standard conforming compiler could do more or less what it wants here (insert malicous code or whatever) - clearly a reason for warning.

While the situation is better in C++11 it is a good idea to avoid situations where the behavior is undefined in earlier versions. The C++03 specification is worse than C99 which outright prohibits such files (behavior is then defined).

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. — supercat, Aug 18 '15 at 20:25

Yasin Bekar · Answer 10 · 2022-09-04T05:35:59.967

0

In my case, I use KOTLIN Language and the compiler is on IntelliJ. Also, I am using a docker container with LINT to fix possible issues with typos, imports, code usage, etc. This error is coming from these lint fixes, most probably - I mean surely.

In short, the error says, 'Add a new line at the end of the file' That is it.

Before there was NO extra empty line:

edited Sep 04 '22 at 05:35

answered Sep 04 '22 at 04:32

Yasin Bekar

127
1
4

score 0 · Answer 11 · answered Jan 07 '12 at 16:19

This warning might also help to indicate that a file could have been truncated somehow. It's true that the compiler will probably throw a compiler error anyway - especially if it's in the middle of a function - or perhaps a linker error, but these could be more cryptic, and aren't guaranteed to occur.

Of course this warning also isn't guaranteed if the file is truncated immediately after a newline, but it could still catch some cases that other errors might miss, and gives a stronger hint to the problem.

"No newline at end of file" compiler warning

11 Answers11

Linked

Related