warning : no new line at end of file
Sameer
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
Rahul Chandok
Can you please type the program you are trying to compile.
It would be helpful for us if you tell us the compilation environment.
for e.g. OS used and compiler version used.
Rahul
Keith Thompson
> when i compile my C programs (even 2 line progs) give the warning, no
> new line at end of file.
> What does this mean ?
It means there's no newline at the end of the file. What do you think
it means?
In your text editor, add a newline to the end of the file you're
trying to compile. (Some editors do this automatically; yours
apparently doesn't.)
--
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.
Richard Bos
> when i compile my C programs (even 2 line progs) give the warning, no
> new line at end of file.
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
Richard
Sameer
#include <stdio.h>
main()
{
printf("hi\n") ;
}
when i compile it i get
warning: no new line at end of file
I am using madrake linux and compiling it with gcc
Sameer
John Smith
> 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?
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.
-- John
Richard Heathfield
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.
--
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)
Richard Bos
> > 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?
Because there are OSes where a text file is stranger even than the
mindset of a Unix-head.
> 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.
The restriction is not on blank lines; the restriction is that the final
line, like all the others, must be properly terminated.
Not all the world is a toy OS from Berzerkeley, you know.
Richard
Afifov
Richard Heathfield
> could it be that you forgot void main()?!
I hope that was intended ironically. In C, main returns int.
Valentin Nechayev
Thu, Dec 29, 2005 at 10:48:30, js (John Smith) wrote about "warning : no new line at end of file":
>> # A source file that is not empty shall end in a new-line character
JS> So the next obvious question is to ask why it is this way?
Because unterminated text line isn't proper text line.
JS> I personally think it's one of the most dumb restrictions ever made. Does it
JS> change anything about how the program is compiled? No! I mean, who cares
JS> about blank lines. It's the code which is important.
JS> Apple also seems to have disabled this in their version of gcc on Mac OS X.
Stock gcc doesn't require termination of last line, but warns for
its.
-netch-
Chuck F.
>
> 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 ?
It means that there was no newline character at the end of the
source file. You must be failing to hit <ret> (or <enter>) after
typing the last source line in your editor.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Afifov
post excluded the return statement, which i was referring to.
Chuck F.
Who is 'you'? The first post in this newsgroup occurred something
like 40 years ago, and I don't think it is available anywhere.
Some people cooperate and include proper context and attributions
in their reply articles. Other rude ones don't bother and just
waste everybodies time and bandwidth.
Richard Bos
> you must
_Who_ must? Learn to quote context! This is not a web board where
anything goes.
Richard
Kenny McCormack
Kenny McCormack
Chuck F. <cbfal...@maineline.net> wrote:
>Afifov wrote:
>>
>> 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.
>
>Who is 'you'? The first post in this newsgroup occurred something
>like 40 years ago, and I don't think it is available anywhere.
>Some people cooperate and include proper context and attributions
>in their reply articles. Other rude ones don't bother and just
>waste everybodies time and bandwidth.
You (and others, such as Keith) are wasting your breath. They'll never get
it. And I'll tell you why.
Imagine that there's a mouse - and the mouse is the Usenet. You and I can
see that it is a mouse and we behave accordingly. But now there is a class
of users (we'll call them "googlers") that are wearing these funny weird
glasses that make them see not a mouse, but an elephant. Seeing an
elephant (i.e., the Usenet as a web page), they also behave accordingly.
And no amount of verbiage from us is going to convince them that it's not
an elephant - that it is only a mouse.
To make this more clear, to a googler, it doesn't make any sense to "quote"
(whatever the heck that is...), in fact, to do so would be absurd, when all
the rest of the articles in the thread are right there in front of their
faces (just as clear as the trunk on that mouse, er, elephant). And no
amount of verbiage from us is going to convince them not to believe what
they see. The point is you can *never* convince someone that what they see
isn't reality. The only way you can address the problem is to help them
fix their eyesight (or help them remove their funny glasses).
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>[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" ?
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
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
Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
...
>> >_Who_ must? Learn to quote context! This is not a web board where
>> >anything goes.
>>
>> From his point of view, it *is*.
>
>Since when is that any excuse?
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
McCormack) wrote:
>In article <dp0cma$gj4$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
>Richard Heathfield <inv...@invalid.invalid> wrote:
>>[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.
--
Al Balmer
Sun City, AZ
Niklas Norrthon
> 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 ?
It means that there isn't a newline at the end of the file.
/Niklas Norrthon
Niklas Norrthon
Samer wrote earlier in the thread:
>> 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 ?
"Afifov" <afi...@yahoo.com> writes:
> could it be that you forgot void main()?!
Please provide context!!!
May I ask why you think a warning about a missing newline would
have anything to do with "void main()" whatever that is?
By the way in C main returns int. Always!
/Niklas Norrthon
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
Please don't feed the troll. Thank you.
nelu
Martin Ambuhl wrote:
> 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
"John Smith" <j...@x-formation.com> wrote in message
news:43b3b125$0$1791$edfa...@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.
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
>> 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.
In article <1135884194.3...@g49g2000cwa.googlegroups.com>
nelu <tanda...@gmail.com> wrote:
>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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Flash Gordon
> Martin Ambuhl wrote:
>> 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
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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jack Klein
Bos) wrote in comp.lang.c:
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*.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
nelu
Flash Gordon wrote:
> nelu wrote:
> > Martin Ambuhl wrote:
> >> 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
>
> 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
<j...@x-formation.com> wrote:
>> 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?
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
--
----== 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 Bos
> In article <43b3fe3b....@news.xs4all.nl>,
> Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
> ...
> >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.
Be grateful for small mercies: trolls would take precedence.
Richard
Afifov
us have to work.
Jordan Abel
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
>> 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?
>
> change anything about how the program is compiled? No! I mean, who cares
> about blank lines. It's the code which is important.
>
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
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
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.
:-)
nelu
Keith Thompson wrote:
> 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.
Excuse me for being off-topic, just for a second, but, just out of
curiosity, what editor is the most used on clc?
John Smith
>
> 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
>
Evidence? How about my eyes and fingers to type with? I've been using OS X
10.3 for the last year and also 10.4 for some months. I initially ported
some software for OS X and didn't even know about the new line issue until I
went on porting it to linux. So this behaviour is the same for both gcc 3.x
and 4.x provided on OS X.
I havn't actually used the editors on OS X. Most of my code has been just
cross developed. I work on one machine and compile on another.
-- John
Jordan Abel
evidence would be, for example, a hexdump of a file that you think does
not end in a newline, that OSX gcc accepts.
tmp123
Keith Thompson
> How do you explain the exit codes of "grep"?
Surely you've seen <http://cfaj.freeshell.org/google/>. That URL has
been posted to this newsgroup 127 times in the last month (according
to Google). If you don't provide some context, don't expect anyone to
know what you're talking about -- and don't expect anyone to go to the
extra effort to find out.
"grep" is a system-specific program. It exists on Unix-like systems,
and there are undoubtedly implementations of it on other systems. It
is therefore off-topic. If you want to understand its exit codes, you
should read the documentation that should be available on any system
that has the command.
If you're wondering why the exit codes aren't limited to 0,
EXIT_SUCCESS, and EXIT_FAILURE, there's no particular reason why they
should be. If exit() is called with any other value, the status
returned is implementation-defined. Since the "grep" command is
implementation-specific, that's perfectly appropriate. It's not even
required that "grep" is implemented in C or uses exit(). (If "grep"
were ported to VMS, presumably the exit codes would have to be
changed.)
Gordon Burditt
>and there are undoubtedly implementations of it on other systems. It
>is therefore off-topic. If you want to understand its exit codes, you
>should read the documentation that should be available on any system
>that has the command.
>
>If you're wondering why the exit codes aren't limited to 0,
>EXIT_SUCCESS, and EXIT_FAILURE, there's no particular reason why they
>should be. If exit() is called with any other value, the status
>returned is implementation-defined. Since the "grep" command is
>implementation-specific, that's perfectly appropriate. It's not even
>required that "grep" is implemented in C or uses exit(). (If "grep"
>were ported to VMS, presumably the exit codes would have to be
>changed.)
There are a lot of programs whose job is to test something, where
the result is necessarily three-way (or more than three):
test result is true
test result is false
unable to conduct test (possibly subdivided into: bad test syntax,
file open failed, division by zero, unable to log into database, etc.)
How you map that into EXIT_SUCCESS, EXIT_FAILURE, and other
allowed exit codes that aren't either is up to you.
Exit codes that *SHOULD* have been standardized, but aren't:
EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
EXIT_FAILURE_YOU_ARE_FIRED
EXIT_FAILURE_AND_YOU_WILL_BE_EXECUTED_BY_FIRING_SQUAD
Gordon L. Burditt
Mark McIntyre
<tanda...@gmail.com> wrote:
>Excuse me for being off-topic, just for a second, but, just out of
>curiosity, what editor is the most used on clc?
If you have a new question, start a new thread, and don't x-post to an
unrelated group.
Mark McIntyre
<tmp...@menta.net> wrote:
>How do you explain the exit codes of "grep"?
In iambic pentameter.
(since you provided absolutely no context, I chose to interpret your
question as "using what delivery style...")
--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.
Richard Heathfield
> On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
> <tmp...@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.
--
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)
Richard Heathfield
nelu said:
> Excuse me for being off-topic, just for a second, but, just out of
> curiosity, what editor is the most used on clc?
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.
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.
Keith Thompson
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.)
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.
> 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
Heathfield <inv...@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
--
Richard Heathfield
>
> 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. :-)
toby
> "John Smith" <j...@x-formation.com> wrote in message
> news:43b3b125$0$1791$edfa...@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?
>
>
> > 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.
>
> 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:1136179621....@z14g2000cwz.googlegroups.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