EOF (novice)

[Alan Connor]

--
Alan C this post ends with w
q

From K&R:

#include <stdio.h>

main()

/* copy input to output */

{

int c;

c = getchar();
while (c != EOF) {

putchar(c);
c = getchar();

}

}


If I am reading the text correctly, this program should
terminate when I enter -1 (EOF as defined on my system,
Linux).

But it doesn't. Just keeps right on trucking.

What gives?

AC

 

[Seesaw]

When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.

 

[Alex]

Absolutely nothing.

Also,

"And sigs are limited to the four lines immediately below the delimiter.

Killfiled for 30 days.

Clean up your act."
Alan Connor, comp.lang.c, Nov 14, 2003.

Alex

 

[Alan Connor]

When you enter -1, you enter two characters '-' and '1'. Neither equals -1.
Maybe you should enter Ctrl-D(?), which will produce a EOF.

Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.


AC

 

[Morris Dovey]

Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.

Alan...

The mechanism for causing an end-of-file condition to be
recognized varies from platform to platform, from OS to OS, and
sometimes from implementation to implementation. There isn't a
single right answer that could've been included in the FAQ or in K&R.

Usually (but not always), not being able to find some piece of
information in both the FAQ and K&R is a clue that the
information sought will depend on either the platform, OS or
implementation.

But thanks for remembering to check the FAQ before posting.

 

[Alan Connor]

Alan...

The mechanism for causing an end-of-file condition to be
recognized varies from platform to platform, from OS to OS, and
sometimes from implementation to implementation. There isn't a
single right answer that could've been included in the FAQ or in K&R.

Usually (but not always), not being able to find some piece of
information in both the FAQ and K&R is a clue that the
information sought will depend on either the platform, OS or
implementation.

But thanks for remembering to check the FAQ before posting.

And the above is EXACTLY what should be in both K&R and the FAQ, as
well as clues such as offered by Seesaw.

Otherwise you have a novice with a program that just won't stop.

and not a clue as to what to do about it.

Thanks much, Morris.

AC

 

[Morris Dovey]

And the above is EXACTLY what should be in both K&R and the FAQ, as
well as clues such as offered by Seesaw.

Otherwise you have a novice with a program that just won't stop.

and not a clue as to what to do about it.

Aha! You've just discovered the value of usenet!

A document that answered all possible questions would be
impossibly large - too large to be generally useful. Steve's FAQ
is actually a really good compendium of the /most/ Frequently
Asked Questions (particularly so when we consider that it's free
and the product of donated - but none the less valuable - time
and effort.)

K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged. It's a different mode of presentation than
used by most authors; and it demands more of the reader. Don't
let yourself be put off just because they're not condescending.

 

[Alan Connor]

K&R attempts (and succeeds) in providing a /succinct/
presentation of the language. Messrs Kernighan and Ritchie
/don't/ spoon feed the reader; they expect us to read with our
brains fully engaged.

That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.

You were. There was a time when you thought a pointer was
a kind of domestic dog.

 

[Arthur J. O'Dwyer]

That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

That's because K&R is a book about *C*, not *Unix*. You
wanna learn Unix, go buy a book about Unix. You wanna learn
MS-DOS, go buy a book about MS-DOS. You wanna learn VMS...
well, you get the idea.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

Bring it up with Ken Thompson next time you see him.
Personally, I like DOS's Ctrl-Z convention better than
Unix's Ctrl-D, 'cause Z "looks like" EOF in that they're
both ends of things (alphabet and file, respectively).
But that's just not the way your operating system works.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

Good for you. So, knowing sh, and running a Linux
machine, surely you should have used 'cat' once or twice
from the command line, right? If so, you have no excuse.
If not, well, okay, just go back up and read that paragraph
advising you to learn *nix from a *nix book.

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

<OT>
Ctrl-C, in Unix, *is* an "emergency out."
Ctrl-D is an EOF "marker" of sorts.
Ctrl-Z will halt the current process.
There are some other Ctrl-[key] combinations that
work on my machine, but they're also off-topic here.
</OT>

HTH,
-Arthur

 

[Mike Wahler]

That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

Because neither of those 'keystrokes' (or any others)
are defined by the language. They're defined by the
host operating system.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

Because C does not have any 'key bindings'. Nor is there
any requirement that standard input be connected to a keyboard
at all.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.

I don't think he does. I think Morris does a fine job
of helping novices with C.

You were. There was a time when you thought a pointer was
a kind of domestic dog.

False context. Shame, shame.

-Mike

 

[Les Cargill]

That's a strange way to put it: "spoon feed".

It is a book written for people who already know how to
program and want to learn C.

And that is what it does.

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

Well, it used to be CTRL-Y for BASIC prgams on HP minis. Mighta
worked for other languages, don't remember.

It's a pseudo-standard.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

(and I studied the header files too)

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if
you weren't one yourself at some point.

We all were, but the sign helps folks know how best to
help people.

You were. There was a time when you thought a pointer was
a kind of domestic dog.

Nuh uh. A sister. Hot, boinin, doin tha neutron dance...

 

[Mac]

Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

There isn't a single clue to be found.

Yet a large number of people here keep saying that K&R is for
beginners.


AC

At the risk of telling you what you already know (in which case lets just
say its for the lurkers) Ctrl-c and Ctrl-d do two very different things.
Ctrl-d is the console's way of saying end of file during interactive
sessions. Ctrl-c raises a signal which, causes naive programs to terminate.

Mac
--

 

[Richard Heathfield]

Thanks, Alan, for this beautifully clear article, with its admirable brevity
and, in a complete turn-about from your normal style, its scintillating
charm and wit.

Oh, by the way, we have a guy round here, a Mr Connor, who is very big on
netiquette, and especially sig block sizes. Please keep your sig block to
four lines or below in future. 30+ lines is just not acceptable.

Thanks.

(Alan's sig block was trimmed from this reply by my newsreader, so I don't
actually know what it says without digging it out from the original, so I
guess his C question, if he had one, will have to go swing.)

 

[Alan Connor]

Thanks for the insight and the good humor from:

Arthur

Les

Mike

Mac

-----------------

I guess I had better follow Morris's advice and "fully engage
my brain".

Now: If I could just remember where I put it. Kinda squishy, right?
Maybe the size of a cantaloupe?

AC

 

[Morris Dovey]

That's a strange way to put it: "spoon feed".

??? That may be a "midwesternism" (USA central region) for being
given information in (small) measured amounts so as to not
overwhelm the recipient.

It is a book written for people who already know how to
program and want to learn C.

True. Doesn't that describe you?

No amount of "brain engaging" could EVER have arrived at the
use of Ctrl-c or Ctrl-d for that program.

True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.

The point you're missing is that the mechanism for *generating*
an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.

There was not a single clue that could possibly lead ANYONE to
those keybindings.

Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had
difficulties.

(and I studied the header files too)

This is evidence that my comment about bindings is accurate.

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

You seem to attach some sort of stigma to novices, as if you
weren't one yourself at some point.

No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.

You were. There was a time when you thought a pointer was a
kind of domestic dog.

Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.

 

[Alan Connor]

True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.

You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

That part of the book is POORLY WRITTEN. Lame.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.

That's bizarre, but why not? The KB is only *standard* input.

The point you're missing is that the mechanism for *generating*

an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.


Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had

difficulties.

Kind of you.

This is evidence that my comment about bindings is accurate.


No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.

That's pretty hardcore.

Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.

I am finding that assembly language is very helpful in understanding
C, which can be just too damned abstract.

Thanks a lot, Morris. Seen any corn lately :-|

AC

 

[Alan Connor]

True. The keyboard mechanism isn't part of the language. The
standard provides a mechanism to recognize the end-of-file
condition for a /stream/ without requiring that there even /be/ a
keyboard associated with any of those streams.

You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

That part of the book is POORLY WRITTEN. Lame.

BTW, on one of my systems Ctrl-Z generates EOF; and on another
Ctrl-X has the same effect. A number of the machines I've
programmed in C have no keyboard at all.

That's bizarre, but why not? The KB is only *standard* input.

The point you're missing is that the mechanism for *generating*

an EOF condition from a keyboard is /not/ a C language issue and
should be described in other, probably OS, documentation.
*Testing* for the condition within a C program /is/ a C language
issue and should be described in C language documentation.


Appropriate, if not convenient. The key bindings aren't
determined by (or relevant to) the C standard. BTW, one of the
advantages of becoming familiar with the standard is knowing what
/is/ and what is /not/ part of the language. I'm sorry you had

difficulties.

Kind of you.

This is evidence that my comment about bindings is accurate.


No, I really don't attach any sort of stigma to any stage of
development. Actually, I'm pleased that you're interested in at
least one of the same things that I find fascinating; and I'm at
least a bit envious that you have free access to the human
resources (via the web and usenet) that weren't available to me
when I began. Strange as it may sound, I'd been programming in C
for more than two years before I met another C programmer - and
for more than a decade before I ever heard of usenet.

That's pretty hardcore.

Actually, I'd been programming in a number of assembly
languages (and a number of high-level languages) for more than
ten years before I started with C. /Addresses/ were actually a
pretty basic concept, and most of the machines I programmed had
/indirect/ addressing modes - which made pointers and
pointers-to-pointers fairly natural to me.

I am finding that assembly language is very helpful in understanding
C, which can be just too damned abstract.

Thanks a lot, Morris. Seen any corn lately :-|

AC

 

[Nils Petter Vaskinn]

You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

That is because of the user not understanding what the program is supposed
to do.

If you thought typing '-' and then '1' would make the program stop you
need to go back and read again since the program reads one character at a
time and echoes it back. '-' and '1' would be two separate characters.

That part of the book is POORLY WRITTEN. Lame.

No, all of the book is written with the assumption that the reader is
already a programmer, and is familiar with his choice of operating system.

The alternative would be to write a book "The C Programming Language on
FOO" where FOO is an operating system, having several versions of the
book, and making a new one every time a new and "improved" version of the
OS is out.

That's the beauty of K&R since it doesn't do OS specific it doesn't get
outdated with the OS-es

That's bizarre, but why not? The KB is only *standard* input.

How is that bizarre? A lot of things have computers in them, (microwave
ovens, dishwashers) without having a keyboard.

And the keyboard isn't standrd, standard inout is whatever the OS tells
the program it is.

An example:
cat foo | bar

Standard input for the program bar isn't the keyboard, but whatever output
comes out of "cat foo"

 

[James Hu]

No amount of "brain engaging" could EVER have arrived at
the use of Ctrl-c or Ctrl-d for that program.

There was not a single clue that could possibly lead ANYONE
to those keybindings.

Unless they already knew at least a high-level language like
sh (that's me).

And even then, whereas I did USE it, I still couldn't relate
it to the text. I thought it was just an "emergency out."

The difference between delivering an interrupt signal and delivering
an "end of input" notification can be observed via an example:

#include <stdio.h>
int main(void)
{
int c;
while ((c = getchar()) != EOF) {
putchar(c);
}
puts("Done");
return 0;
}

You might even try:

#include <stdio.h>
#include <setjmp.h>
#include <signal.h>
static jmp_buf env;
static void interrupted(int s) { longjmp(env, s-s-1); }
int main(void)
{
int c;
if (signal(SIGINT, interrupted) == SIG_ERR) {
puts("Couldn't set signal handler for SIGINT");
return 0;
}
if (setjmp(env) == 0) {
while ((c = getchar()) != EOF) {
putchar(c);
}
puts("Done");
} else {
puts("Interrupted");
}
return 0;
}

-- James

 

[CBFalconer]

. snip ...

That is because of the user not understanding what the program is
supposed to do.

If you thought typing '-' and then '1' would make the program stop
you need to go back and read again since the program reads one
character at a time and echoes it back. '-' and '1' would be two
separate characters.

And I doubt very much that K&R ever suggested exiting the program
by generating -1. They may well have suggested testing the input
value against EOF, which is not necessarily the value -1. The
elementary and obvious technique of looking up EOF in the index
would lead to further information which in turn makes the use of
-1 obviously foolish.

Using the above esoteric technique I found information on EOF on
page 16 of K&R2. This would appear to indicate that Mr. Connor
has not read and absorbed the first 16 pages. He is thus
eminently qualified to criticize the books usefulness as
instructive material.