warning : no new line at end of file

[Kenny McCormack]

[Followups set to comp.lang.c]

John Smith said:

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

Presumably because a source file is intended to be a text file, and a text
file comprises zero or more lines, and a line comprises zero or more
characters terminated by a newline character.

Let's see... How does one spell "pedant" ?

P.S. To Mr. Smith, the reason is that it doesn't matter on Unix and other
well-behaved OS's, but it might matter elsewhere. Or, to put it another
way, it should be possible to write the compiler front-end in (100%)
standard C, and standard C requires that text files be well-behaved.

 

[Richard Bos]

From his point of view, it *is*.

Since when is that any excuse? From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

Richard

 

[Kenny McCormack]

From his point of view, it *is*.

Since when is that any excuse?[/QUOTE]

It is not an excuse. I really don't see where you (and others) get the idea
that I am excusing anyone.

It is, rather, an *explanation*, and a suggestion to you, the regulars,
that you find other ways to deal with it. The point is, as I explain every
time I post my little treatise on the subject, you simply *cannot* convince
someone that what they see isn't reality.

From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

I think we'd all be much happier if you did.

 

[Al Balmer]

[Followups set to comp.lang.c]

John Smith said:

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?

Presumably because a source file is intended to be a text file, and a text
file comprises zero or more lines, and a line comprises zero or more
characters terminated by a newline character.

Let's see... How does one spell "pedant" ?

It's spelled "computer program" or "parser." Computers tend to be very
pedantic, and not recognize even trivial deviations from the rules
they live by.

P.S. To Mr. Smith, the reason is that it doesn't matter on Unix and other
well-behaved OS's, but it might matter elsewhere. Or, to put it another
way, it should be possible to write the compiler front-end in (100%)
standard C, and standard C requires that text files be well-behaved.

It's not the OS, but whether the compiler accepts EOF as equivalent to
newline in that context.

Whether the compiler can reliably do that may depend on the OS, or
more exactly, the file system.

 

[Martin Ambuhl]

could it be that you forgot void main()?!

What the hell is this about?

If you mean that someone should delare main to have a return type of
void, then you are severely in error.

If you mean he should void such code into the porcelon throne, then you
are probalby right.

 

[Martin Ambuhl]

you must declare main to be int and return 0. The person with the first
post excluded the return statement, which i was referring to.

main may also return EXIT_FAILURE and EXIT_SUCCESS. For
implemetation-specific non-portable code, other implementation-defined
values are possible. It is not true that main must return 0.

 

[Keith Thompson]

Since when is that any excuse? From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

Please don't feed the troll. Thank you.

 

[nelu]

main may also return EXIT_FAILURE and EXIT_SUCCESS. For
implemetation-specific non-portable code, other implementation-defined
values are possible. It is not true that main must return 0.

I know that EXIT_SUCCESS==0 on all the platforms I've used C on and I
used to write return 0 in main all the time but since the C standard
defines EXIT_SUCCESS and EXIT_FAILURE in <stdlib.h> and they should be
used by 'exit' is it correct (not program correctness, but C standard)
to ever explicitly return 0?
I got used to 0 from Visual C++ 5, I think, and I noticed that the
KDevelop template for the main function in a C program terminates with
'return EXIT_SUCCESS'.

 

[David Schwartz]

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.

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

 

[Chris Torek]

I know that EXIT_SUCCESS==0 on all the platforms I've used C on ...

It happens to be defined as 1 on VMS (where 1 is the general-purpose
OS "success" code).

... is it correct (not program correctness, but C standard)
to ever explicitly return 0?

It is valid to do so. A Standard C system must convert an exit(0),
or the (mostly) equivalent "return 0" from initial call to main, into
(one of) the OS's "success" code(s). On VMS in particular, this
means that exit(0) and exit(1) do the same thing.

(Older, pre-ANSI-C-standard versions of VMS fail to convert 0 to 1,
so that in VMS 3.0, returning 0 from a C program causes the system
to claim the program failed.)

If the OS happens to have two or more different "kinds" of "success",
a C implementation for that OS is allowed to have EXIT_SUCCESS
produce one of them and 0 produce another (different) one.

 

[Flash Gordon]

I know that EXIT_SUCCESS==0 on all the platforms I've used C on

It is not required to be, but it is not surprising. See below...

> and I
used to write return 0 in main all the time

This is perfectly valid.

> but since the C standard
defines EXIT_SUCCESS and EXIT_FAILURE in <stdlib.h> and they should be
used by 'exit' is it correct (not program correctness, but C standard)
to ever explicitly return 0?

<snip>

The standard defines returning 0 from the initial call to main (or doing
exit(0)) indicates success. It also defines EXIT_SUCCESS and
EXIT_FAILURE which can also be used either returning from the initial
call to main or when calling exit and they have the obvious meanings.

 

[Jack Klein]

Since when is that any excuse? From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

Richard

I've asked you before not to respond to this particular troll, whom I
would not see at all if it were not those, like you, who feed him.

Sorry, but *plonk*.

 

[nelu]

It is not required to be, but it is not surprising. See below...

I know it is not required, it was 0 on the systems I worked with. I
didn't know that return 0 should be transformed into success. Thanks!

 

[Mark McIntyre]

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

I suspect its to do with how some machines store files, and more
specifically how they know they've reached the end of a line.

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.

Its not a /blank/ line thats required, its a newline character.

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

Try setting warning levels a little higher.
Mark McIntyre

 

[Richard Bos]

I think we'd all be much happier if you did.

Be grateful for small mercies: trolls would take precedence.

Richard

 

[Afifov]

i am amazed how some of u have so much time for these long posts. some of
us have to work.

 

[Jordan Abel]

Since when is that any excuse? From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

Richard

And besides, quoting is common on web boards. It's generally done with a
blockquote-like bbcode tag, but is still done nonetheless.

 

[Jordan Abel]

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

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.

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

What is your evidence for this claim?

note that this does not mean that it should end with a blank line.
Traditionally, every line of a text file ends in a newline character. I
suspect the editors you are using on OSX provide it. This doesn't mean
there is a blank line

There is a newline at the end of this post [technically a carriage
return and a linefeed, since that's how text-based network protocols
tend to do things.]

 

[Keith Thompson]

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

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.

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

What is your evidence for this claim?

note that this does not mean that it should end with a blank line.
Traditionally, every line of a text file ends in a newline character. I
suspect the editors you are using on OSX provide it. This doesn't mean
there is a blank line

There is a newline at the end of this post [technically a carriage
return and a linefeed, since that's how text-based network protocols
tend to do things.]

Whether a text file includes a proper newline on its last line can
depend on which text editor you used to create it.

Discussion of questionable topicality follows (it's topical in
comp.unix.programmer, but at best marginally so in comp.lang.c).

On Unix-like systems, most or all versions of vi (vi, nvi, vim, etc.)
add a newline automatically. If you edit a file that lacks a trailing
newline, it will add one when you update the file. As far as I know,
it's nearly impossible to create a mal-formed text file with vi.

The behavior of emacs, on the other hand, can be configured by setting
the "require-final-newline" variable. By default, emacs will silently
create a file with no trailing newline. It can also be configured
either to silently add a newline, or to ask what to do. I have the
line
(setq require-final-newline 'ask)
in my $HOME/.emacs file.

Other systems and other editors will have different ways of handling
this.

 

[Mark McIntyre]

i am amazed how some of u have so much time for these long posts. some of
us have to work.

Perhaps some of yuo ought to consider a job that allows you to take
paid holidays, and doesn't require you to work evenings and weekends.




Mark McIntyre