just got myself a copy of K&R...

[Kevin Bracey]

In message <[email protected]>

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF.

There usually _is_ something you can enter as a user to signal EOF. On many
systems, Ctrl+D will do it. Check your implementation's documentation. Also,
if you redirect stdin from a file (usually by using "< filename", you will
get EOF when it reaches the end of the file.

 

[Fao, Sean]

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operator
and remembering how they are used (I was no more then 10 or 11 years old at
the time).

Yeah, a common mistake. I think it derives from the elementary-level
schools focusing on rote memorization instead of problem-solving.
While rote memorization is useful in programming, it certainly doesn't
aid the learning of the language beyond a certain level.

[...]

I never thought about it before but you're probably right. Looking back
at those days, I *was* taught to memorize --_everything_. It probably
also explains why I was such a bad speller up until the point that I
finally stopped trying to remember how to spell everything and learned
how to "sound it out" for myself. I'm still not great but I can
honestly say that I've improved quite a bit. It's funny how I was never
like that with math. I seemed to do quite well teaching myself. But
maybe that's just it. I had an interest in the subject and realized at
an early age how to think through a problem rather then trying to
remember a bunch of seemingly meaningless formulas.

Interesting...Thanks for the brain storm .

Sean

 

[Fao, Sean]

"Fao, Sean" <[email protected]> wrote in message

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operator
and remembering how they are used (I was no more then 10 or 11 years old at
the time).

Yeah, a common mistake. I think it derives from the elementary-level
schools focusing on rote memorization instead of problem-solving.
While rote memorization is useful in programming, it certainly doesn't
aid the learning of the language beyond a certain level.

[...]

I never thought about it before but you're probably right. Looking back at
those days, I *was* taught to memorize --_everything_. It probably also
explains why I was such a bad speller up until the point that I finally
stopped trying to remember how to spell everything and learned how to "sound
it out" for myself. I'm still not great but I can honestly say that I've
improved quite a bit. It's funny how I was never like that with math. I
seemed to do quite well teaching myself. But maybe that's just it. I had
an interest in the subject and realized at an early age how to think through
a problem rather then trying to remember a bunch of seemingly meaningless
formulas.

Interesting...Thanks for the brain storm .

Sean

 

[Fao, Sean]

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

He didn't say you couldn't use it to learn programming if you had no
prior experience, but the book does assume that you have prior
experience. Bottom line, it doesn't bore the reader with stuff like,
"there are these things called variables which are named memory
locations and we use them for ..." and "to count in binary, we do ...".

 

[Arthur J. O'Dwyer]

The above is undefined, and will only work if EOF is ^^^^^^^^^
actually defined to be -1.

Nitpick: I see no undefined behavior here. At most, it's
unspecified behavior. Either:

Case 1. sizeof(int)==sizeof(char).
I have no idea. You're pretty much screwed anyway,
though, since most of the text I/O stuff won't work
in any kind of user-friendly manner.

Case 2. sizeof(int)>sizeof(char) && EOF == -1.
The code works as expected, breaking the loop when
the end of input is encountered.

Case 3. sizeof(int)>sizeof(char) && EOF != -1.
The code does not work as expected; the condition
never becomes true and the loop never terminates.

One of Cases {1,2,3} *must* be the case, unless I'm
missing something fairly basic here. And that makes
it "unspecified," albeit depending on various
implementation-defined characteristics.


Everything else good, though.

-Arthur

 

[Alan Connor]

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

But not to the thousands who have been completely discouraged by the
book and by the many arrogant elitists found in the field.

 

[Richard Heathfield]

But not to the thousands who have been completely discouraged by the
book and by the many arrogant elitists found in the field.

Please provide evidence for your assertion that "thousands have been
completely discouraged by the book". Thank you.

 

[Lew Pitcher]

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Alan Connor]

"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.

"The book is not an introductory programming manual..." K&R

"K&R assumes that you already know how to program....." Me

May I suggest a good ESL course? Logic 101? Hormones?

 

[Jirka Klaue]

....
So if your point was that EOF can be returned for a reason other than
I'm-all-out-of-data, then you're correct - it can also be returned on
error. Otherwise, I am not sure what your point is.

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too. That's why my point was, as you noted, that EOF
could be returned for some other reason than end-of-file. Only that I
did have one more reason in mind.
The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Jirka

 

[Mark McIntyre]

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too.

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.

The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

 

[Jirka Klaue]

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.

It would have a possible value. That this value could be used for data
does not matter. Where does the standard say otherwise?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

Can you provide an example using EOF, which can not be rewritten
using feof()? I'm curious.

Jirka

 

[Joe Wright]

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.


Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

If 'while ((c = getchar()) != EOF) {}' doesn't work for you, why not..

'while ((c = getchar()), ! feof(stdin)) {}'

 

[Mark McIntyre]

It would have a possible value. That this value could be used for data
does not matter. Where does the standard say otherwise?

It says that EOF must mean "no more data", which I believe precludes
it from sharing a value with actual data.
If the value of EOF were shared with a real value, there would be no
way for the implementation to reliably signal an error or end-of-data
condition. Some functions are required to do that, so the
implementation could not conform to the requirements of the standard.

Can you provide an example using EOF, which can not be rewritten
using feof()? I'm curious.

EOF is used to indicate errors from the character i/o functions. I'm
not sure you can detect errors in fputc otherwise, and I'm pretty sure
feof won't help.

int c = fgetc(stdin);
if(c==EOF)
printf("there was an error reading from stdin, \
but its unlikely to have been an \
end-of-file condition I think...\n");
int cc = fputc(c, stdout);
if(cc==EOF)
printf("there was an error writing to stdout, \
but its not an end-of-file condition\n");

 

[Lew Pitcher]

"The book is not an introductory programming manual..." K&R

"K&R assumes that you already know how to program....." Me

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

I reiterate: It looks like the authors of K&R do not agree with you, Alan.
I will give you this: I can't find any evidence to indicate that K&R
/disagree/ with you. They simply do not state anything on the topic.

May I suggest a good ESL course? Logic 101? Hormones?

May I suggest better glasses? Perhaps a course in Technical Writing? Or even
just a parachute for your "jumping to conclusions"?

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Chris Torek]

If 'while ((c = getchar()) != EOF) {}' doesn't work for you, why not..

'while ((c = getchar()), ! feof(stdin)) {}'

It is an infinite loop when getchar() returns EOF due to input
error (in which case, c==EOF, feof(stdin)==0, and ferror(stdin)!=0).

You can fix this with:

while ((c = getchar()), !feof(stdin) && !ferror(stdin))
...

but I prefer the "c != EOF" test. Systems that have stdio return
valid input data that compares equal to EOF appear to have too many
tough problems implementing the C library, so I choose (consciously,
not accidentally) to avoid them instead of accomodating them.

 

[Alan Connor]

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

I reiterate: It looks like the authors of K&R do not agree with you, Alan.
I will give you this: I can't find any evidence to indicate that K&R
/disagree/ with you. They simply do not state anything on the topic.


May I suggest better glasses? Perhaps a course in Technical Writing? Or even
just a parachute for your "jumping to conclusions"?

Lew, listen really closely: You are wrong. You are reading English as
if it was a computer language. It isn't. It's much more complex than
that.

Read the meaning of the statement from K&R as a WHOLE, not the sum of
its parts and not limiting your definitions of the words to one definition,
because the dictionary certainly doesn't.

Look at the "spirit" of the sentence, as in the "spirit of the law".

The authors clearly mean (no Lew, not every word of meaning in a sentence
is literally there) that the book is for people that already know another
language.

Where else is one going to gain "some familiarity with programming concepts"
except by learning a language?

Maybe playing tennis at the club? In Political Science maybe?

And the AMOUNT of prior knowldge they require is considerable.

("some" is not a precise term, Lew)

I know that because I am very new to computers and when I first picked up
K&R it may as well have been in Swahili.

Only after learning how to program in Bash (which IS a high-level programming
language) could I begin to make sense out of K&R.

But you believe what you want. I couldn't care less and am bored with this.

 

[Alan Connor]

Well Lew, fortunately the Computer Science Professors of America
don't agree with you on this.

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

I don't think you can find an exception to this.

 

[Richard Bos]

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

In theory, you are correct. In practice, though, I know nobody who is
familiar with programming concepts to the level needed to use K&R
without problems, but does not know how to program. There just aren't
any courses that teach "assignment statements" and "functions" without
also teaching how to program in one language or another.

Admittedly, "one language or another" may be MIX...

Richard

 

[Lew Pitcher]

Well Lew, fortunately the Computer Science Professors of America
don't agree with you on this.

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

I don't think you can find an exception to this.

It looks like you are right.

I cannot find any counter-examples, and while K&R may have somehow intended
that "The C Programming Language" be a standalone tutorial, it cannot be
said that it /is/ a standalone tutorial.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.