warning : no new line at end of file

[Sameer]

Hi,
when i compile my C programs (even 2 line progs) give the warning, no
new line at end of file.
What does this mean ?
-Regards,
Sameer

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalid> writes:

Mark McIntyre said:

On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
<tm****@menta.net> wrote:

How do you explain the exit codes of "grep"?

In iambic pentameter.

Your wish is my command.

Now grep has quite a wonderful design,
And purposes untold and without number;
When searching for that quintessential line,
You know your trusty grep will never slumber,
Seeking, seeking, all throughout its sessions,
With full support for regular expressions.

But if you execute it from a shell script,
Wanting total searching automation,
You really need a way that you can decrypt
Those exit codes, a most complete translation.
Here's a guide to help you understand them,
So that you need not yet all hope abandon:

When grep yields zero, questing is completed,
And nothing sought remains to be disclosed;
But if our hero hands you one, defeated,
No answer is there to the search you posed;
And when your shell script with a two is treated,
Your files are wrong, or your argv is hosed.

Alas, your talk of grep, though it's quite pretty,
Is not on topic here in comp lang c.
And though to criticize you is a pity,
We must maintain our rules of pedantry.
Bandwidth is cheap, and yet we must be frugal.
(It could be worse; at least you don't use Google.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[nelu]

Richard Heathfield wrote:

In comp.lang.c, that's a bit like asking "what colour socks do C hackers
prefer?" Yes, there is an answer, but no, you'll probably never find out
what it is, because comp.lang.c subscribers don't actually care what the
answer is. Yes, I guess I was way off :-).
The comp.unix.programmer and comp.lang.c newsgroups have good historical
reasons for being fluffy-bunny snuggly companions, but in practice C has
spread far and wide since those halcyon days of the 1973 kernel, and the
comp.lang.c group no longer thinks of C as being merely another word for
Unix. I've hacked out C code in ISPF/PDF, Notepad, vim, elvis, pico, and
a variety of Windows IDEs. I've written C using COPY CON and cat. I have
written C code using custom-written code generators - which can scarcely
count as editors at all. Here in comp.lang.c, the question is simply not
worth asking, I'm afraid.

I was just curios what C programmers prefer to use. Would it be safe,
for example, to guess that you prefer notepad to copy con on a regular
basis? :-)

But you're right, going down this path usually leads to things that
have nothing in common with C, so I hope people will disregard that
post.

[Mark McIntyre]

On Sun, 1 Jan 2006 05:44:34 +0000 (UTC), in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

(snip most excellent verse rendition of the return codes of grep).

Your sig seems curiously appropriate.... :-)

"Usenet is a strange place" - dmr 29/7/1999

Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Richard Heathfield]

nelu said:

Richard Heathfield wrote:

In comp.lang.c, that's a bit like asking "what colour socks do C hackers
prefer?" Yes, there is an answer, but no, you'll probably never find out
what it is, because comp.lang.c subscribers don't actually care what the
answer is. Yes, I guess I was way off :-).

Having established that.....

<snip>
I was just curios what C programmers prefer to use. Would it be safe,
for example, to guess that you prefer notepad to copy con on a regular
basis? :-)

Weeeeelllll, if you must know, I prefer vim. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[toby]

David Schwartz wrote:

"John Smith" <[e-mail]> wrote in message
news:43**********************@dread11.news.tele.dk ...

It means, surprise, surprise, that there is no new-line at the end of
your source file. Quoth the Standard: # A source file that is not empty shall end in a new-line character

So the next obvious question is to ask why it is this way?

So that you can concatenate files together without lines merging.

I personally think it's one of the most dumb restrictions ever made. Does
it change anything about how the program is compiled? No! I mean, who
cares about blank lines. It's the code which is important.

It does change things about how the program is compiled. Your assumption
is erroneous. Failure to end a file with a newline could result in
concatenating two files, causing the last symbol in one to merge with the
first symbol in the next.

Hmm, no, gcc does not mash input files together in this manner. It's
hard to imagine a valid C file that does not end with ; or }. On the
other hand, it is conceivable that a preprocessor directive not ending
in a newline, when manually concatenated with another file to form
input to the compiler, might cause an unexpected problem...

In ages past, I believe such lexical warnings helped flag media
problems such as a missing card, bad parity, truncated file, and such.
I am not certain that remains the rationale for this warning, however
-- since C is strict about nesting braces and statement termination (as
noted above), file corruption is likely to abort compilation anyway.

The other reason is simply for logical consistency. A line is defined to
end with a specific line ending character. A source file is defined to
consist of lines.

Apple also seems to have disabled this in their version of gcc on Mac OS
X.

They are not required to issue a warning.

DS

[David Schwartz]

"toby" <to**@telegraphics.com.au> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

David Schwartz wrote:

So that you can concatenate files together without lines merging. It does change things about how the program is compiled. Your
assumption
is erroneous. Failure to end a file with a newline could result in
concatenating two files, causing the last symbol in one to merge with the
first symbol in the next.

Hmm, no, gcc does not mash input files together in this manner.
Who was talking about gcc?
It's
hard to imagine a valid C file that does not end with ; or }.
On the contrary, most header files end with a preprocessor directive.
On the
other hand, it is conceivable that a preprocessor directive not ending
in a newline, when manually concatenated with another file to form
input to the compiler, might cause an unexpected problem...
Exactly.
In ages past, I believe such lexical warnings helped flag media
problems such as a missing card, bad parity, truncated file, and such.
I am not certain that remains the rationale for this warning, however
-- since C is strict about nesting braces and statement termination (as
noted above), file corruption is likely to abort compilation anyway.

I think it's just for logical consistency. A text file consists of
lines. A line is defined as ending with a line terminator.

DS