Diff has to output a newline anyway, or the result would be harder to read or process automatically. Note that it is a good style to always put the newline as a last character if it is allowed by the file format. It's not just bad style, it can lead to unexpected behavior when using other tools on the file. Maybe that's what you want, but in most cases you'd probably expect there to be 2 lines in the file.
Finally, it would make your diffs slightly more noisy if you were to add a new line. If you added a third line, it would show an edit to the second line as well as the new addition. The only reason is that Unix historically had a convention of all human-readable text files ending in a newline.
At the time, this avoided extra processing when displaying or joining text files, and avoided treating text files differently to files containing other kinds of data eg raw binary data which isn't human-readable. Because of this convention, many tools from that era expect the ending newline, including text editors, diffing tools, and other text processing tools.
Windows wasn't developed to be Unix-compatible, so it doesn't have the same convention, and most Windows software will deal just fine with no trailing newline. But, since Git was developed for Linux first, and a lot of open-source software is built on Unix-compatible systems like Linux, Mac OS X, FreeBSD, etc, most open-source communities and their tools including programming languages continue to follow these conventions.
There are technical reasons which made sense in , but in this era it's mostly convention and maintaining compatibility with existing tools. It just indicates that the end of the file doesn't have a newline. It's not a catastrophe it's just a message to make it clearer that there isn't one when looking at a diff in the command line.
In other words, it shows a larger diff than conceptually occurred. There is one thing that I don't see in previous responses. Learn more. Asked 13 years, 4 months ago. Active 2 years, 9 months ago. Viewed k times. Improve this question. LeChuck2k LeChuck2k. 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. Add a comment. Active Oldest Votes.
Improve this answer. Anne Of course in practice every compiler adds a new line after the include. It was exacerbated because the IDE editor encouraged this sort of missing-newline behaviour. Compilers may not complain currently, but GitHub actually does. 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? Thomas: Is this program invokes undefined behavior because it doesn't end with new line. See program here: ideone. Even so, it probably should be tagged [c], since many people searching for this warning in C will find their way here. This is still a good point to add. Adding this up above. Hope you don't mind. Lightness Races in Orbit k 70 70 gold badges silver badges bronze badges. Igor Semenov Igor Semenov 1, 9 9 silver badges 7 7 bronze badges.
Ahh, the beloved "undefined behaviour". If the file does not end with a newline, the line containing the include that pulled it in will merge with the next line. I am using c-free IDE version 5.
Just at the end of the program i. So you can write a MyHeader. 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. This warning might also help to indicate that a file could have been truncated somehow.
I just put a new line after my code just click enter key the warning vanish away.
0コメント