Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > EOF (novice)

Reply
Thread Tools

EOF (novice)

 
 
Les Cargill
Guest
Posts: n/a
 
      11-19-2003
Alan Connor wrote:
>
> On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey <(E-Mail Removed)> wrote:
>
> > 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.
>


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...

>
> --
> Alan C this post ends with w
> q



--
Les Cargill
 
Reply With Quote
 
 
 
 
Mac
Guest
Posts: n/a
 
      11-19-2003
On Wed, 19 Nov 2003 02:02:27 +0000, Alan Connor wrote:

> On Wed, 19 Nov 2003 01:30:57 -0000, Seesaw <(E-Mail Removed)> wrote:
>>
>>
>> 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


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
--


 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-19-2003
Alan Connor wrote:

>
>


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.)

--
Richard Heathfield : http://www.velocityreviews.com/forums/(E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
Reply With Quote
 
Alan Connor
Guest
Posts: n/a
 
      11-19-2003
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

 
Reply With Quote
 
Morris Dovey
Guest
Posts: n/a
 
      11-19-2003
Alan Connor wrote:

> On Tue, 18 Nov 2003 22:39:09 -0600, Morris Dovey
> <(E-Mail Removed)> wrote:
>
>> 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".


??? 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.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

 
Reply With Quote
 
Alan Connor
Guest
Posts: n/a
 
      11-19-2003
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <(E-Mail Removed)> wrote:
>


<snip>

>> 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.


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.
>
>> 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.


Kind of you.

>> (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


That's pretty hardcore.

>> 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.


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

 
Reply With Quote
 
Alan Connor
Guest
Posts: n/a
 
      11-19-2003
On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <(E-Mail Removed)> wrote:
>


<snip>

>> 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.


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.
>
>> 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.


Kind of you.

>> (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


That's pretty hardcore.

>> 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.


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

 
Reply With Quote
 
Nils Petter Vaskinn
Guest
Posts: n/a
 
      11-19-2003
On Wed, 19 Nov 2003 08:33:49 +0000, Alan Connor wrote:

> On Wed, 19 Nov 2003 01:35:47 -0600, Morris Dovey <(E-Mail Removed)> wrote:
>>
>> 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 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

>> 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.


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"



--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

 
Reply With Quote
 
James Hu
Guest
Posts: n/a
 
      11-19-2003
On 2003-11-19, Alan Connor <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-19-2003
Nils Petter Vaskinn wrote:
> On Wed, 19 Nov 2003 08:33:49 +0000, Alan Connor wrote:
>

.... snip ...
> >
> > 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.


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.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Jan Burse Java 67 03-14-2012 12:21 AM
ifstream eof not reporting eof? SpreadTooThin C++ 10 06-15-2007 08:49 AM
if EOF = -1, can't a valid character == EOF and cause problems? Kobu C Programming 10 03-04-2005 10:40 PM
A question about EOF SL_McManus Perl 1 12-04-2003 01:50 AM
How to check for EOF (End of file) when using StreamReader to parse text file Sacha Korell ASP .Net 2 09-06-2003 02:59 PM



Advertisments