C the complete nonsense

M

Malcolm McLean

I have to say, purely as a point of English usage, that to me "in
general" (as a two word phrase, rather than other uses of "general")
means only "most of the time" or similar, not "always".  There's no
point qualifying what would already be an absolute statement with it
unless it changes the meaning.
Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.
People are like that.
Then I'm attacked for not analysing all of the errata.
 
J

James Harris

....
Schildt's bad explanations are, for the most part, quite consistent.
Look at the way he "explains" EOF.  He shows sample code.  He explains that
the sample code will fail "on binary files".  Sure enough!  If you run that
code on a file people would typically think of as a binary file, on a
typical MS-DOS or Windows system, it almost certainly fails in the way he
describes.  He reveals a solution -- a way to avoid that failure.  Sure
enough!  His proposed solution appears to mitigate the problem.

The victim now believes that Schildt has imparted to him knowledge of a
tricky pitfall in C, as well as a solution -- a way to avoid that pitfall..
He notices that many other programmers don't know about this pitfall, or
use that solution.  He concludes that Schildt's book is very good -- it
covered something many people don't know about.

He recommends Schildt's book, confidently... Unaware that there was never
any problem except that Schildt didn't know what he was doing, and the simple
standard code everyone else is using works fine and is both simpler and
more reliable than what Schildt demonstrated.

Basically, Schildt is living large off the low end of the Dunning-Kruger
curve; people who think they learned C from his books are likely to imagine
that they learned C very well, but in practice, most of them take years
to recover.

Sorry to quote almost the whole post but it's a fascinating
suggestion. Setting up supposed problems with the language and showing
how to solve them possibly gives his readers the feeling that they are
learning some secret knowledge. After all no other book shows this
'insider' information. As you say, readers may be unaware that the
problems didn't really exist in C. Judged in isolation the book would
appear immensely valuable.

And if the examples are complex enough and not easy to remember people
would want to keep the book around in case they are ever faced with a
similar problem and need to look it up.

Maybe there's a suggestion in there for potential authors: use the
same style of showing problems and solutions but do so with real
issues the readers are likely to encounter. Would it work? I don't
know. With a well-designed language there are probably fewer real
issues than imaginary ones.

Regardless, it's an intriguing insight into why Schildt's book may be
popular.

James
 
K

Keith Thompson

Malcolm McLean said:
Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.
People are like that.

We haven't estblished it because there are legitimate differences of
opinion on the point, something I don't recall seeing you acknowledge.
Then I'm attacked for not analysing all of the errata.

No, you're criticized for judging the entire list based on the first
one or two entries.
 
N

Nick

Richard Heathfield said:
Example

This fragment reads up to 128 characters from the file described by fd:

unsigned count
char *buf[128];

if(_dos_read(fd, buf, 128, &count))
printf("error reading file");

In those four lines of code, I can see three bugs without even
trying. The missing semicolon will of course result in a diagnostic
message from the compiler. The missing newline escape sequence may
result in the error output not appearing immediately (or indeed at
all, if it's the last data written to that stream before program
termination). But most importantly, the array is of 128 char *,
whereas it should be of 128 char. He is reading arbitrary byte values
into an array of pointers!

But the worst mistake of all is not a bug in the sense that it's a
code error. The worst mistake is that he utterly fails to explain why
anyone would ever bother to use this function, given the availability
of fread. I'm not saying no such reason exists. I'm saying he fails to
give it.

There's another "non bug" that's pretty important in what is supposed to
be teaching code: that error statement.

I know error handling can clutter example code up, but that line is just
rubbish. A simple
/* handle error */
would have been better in so many ways.

Firstly, what's it doing printing to stdout instead of stderr? And what
is the point of just blithely continuing? The next bit of the code must
be to do something with buf, which you have no way of telling doesn't
contain anything useful. At the very least it needs to be:

if(_dos_read(fd, buf, 128, &count)) {
fprintf(stderr,"error reading file\n");
exit(EXIT_FAILURE);
}

Hardly great, but a world better.
 
N

Nick

Richard Heathfield said:
Oh yes, it's time to play the random game again.

CTCR2e, Herbert Schildt, p152:

For example, consider the function print_upper(), which prints its
string argument in uppercase:

Is that what it says. Because the function doesn't just print the
argument in upper case, it converts the string to upper case.

I ought to be able to expect to use the original string after I've
run something called "print_upper" on it.

Again, I think this is more significant than the more obvious flaws.
#include "stdio.h"
#include "ctype.h"

void print_upper(char *string);

void main(void)
{
char s[80];

gets(s);
print_upper(s);
}

/* Print a string in uppercase. */
void print_upper(char *string)
{
register int t;

for(t=0; string[t]; ++t) {
string[t] = toupper(string[t]);
putchar(string[t]);
}
}
 
M

Malcolm McLean

[...]
Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.
People are like that.

We haven't estblished it because there are legitimate differences of
opinion on the point, something I don't recall seeing you acknowledge.
I don't think "In general", as the opening phrase of a sentence, can
ever mean "always". If we can't even agree on that, there's not much
point going on to erratum number two, where the issues are a bit more
subtle.
 
S

Seebs

Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.
People are like that.

Well, keep in mind, a big part of the point wasn't whether or not the
statement was necessarily and definitely false, but whether it had any
place being there in the first place.
Then I'm attacked for not analysing all of the errata.

The only relevance ever on the table (given that it was Nilges who
asked you to do it) was whether the errata did, or did not, show that
there were serious flaws in Schildt's book. Even if we stipulated
that several of the errata were useless, so what? Look at the
description of order-of-evaluation errors in C:TCN 3e, and try to claim
with a straight face that this could EVER have been written by anyone
who actually knew C at a sufficient level of expertise to be writing
about it.

The EOF thing is also a killer. No matter how easy it is to get things
wrong in code, no one should be getting the basic model of I/O in C wrong.

That was the essential point -- that it simply doesn't matter whether a few
of them are overly picky, because the other errors in Schildt's text are so
incredibly egregious that the question was irrelevant.

-s
 
S

Seebs

I don't think "In general", as the opening phrase of a sentence, can
ever mean "always". If we can't even agree on that, there's not much
point going on to erratum number two, where the issues are a bit more
subtle.

I think there might be a great deal of point in going on to other errata,
if by doing so we could answer the question unambiguously with complete
agreement.

"In general" tends to live right around the level of "it is safe for you
to assume that...", and as such, the claim that computers are "in general"
two's complement strikes me as way too strong. More importantly, though,
it strikes me as irrelevant and inappropriate for that point in the book.

Perhaps even more importantly, Schildt makes other claims about C which
are wrong because he doesn't understand that C does not really specify the
representation, for instance, his claim that right-shifts necessarily
sign-extend.

-s
 
S

Seebs

Maybe there's a suggestion in there for potential authors: use the
same style of showing problems and solutions but do so with real
issues the readers are likely to encounter. Would it work? I don't
know. With a well-designed language there are probably fewer real
issues than imaginary ones.

I used similar constructs and examples in my shell book, for problems
that real readers might encounter, and I have gotten some praise for it.

-s
 
J

James Harris

Time for you to read some Usenet FAQs.  Moving a discussion of MS-DOS
programming to the newsgroup for MS-DOS programming is hardly "playing
around".  Don't unthinkingly follow the bad example of Rod Pemberton's
cluelessness, here.  Put the thinking cap on and think!

You were playing around with headers long before Rod's observation.
And your disparaging remark about him is invalid, by the way. His
comments unfailingly show a good deal of thought, and knowledge of the
subjects under discussion.

Speaking of Usenet I'd ask you when posting if you'd kindly do the
following.

Please change subject lines less frequently than you have been doing.
If necessary it may be better to start a new topic in a new thread. If
you must change a subject line it can be helpful to just add the new
subject leaving some or all of the original text.

Please change cross-post groups less frequently than you have been
doing. That way fewer threads will pop up in new groups without
context.

Please include more context in your quotes. Terse, incomplete
inclusions can misrepresent the person you are quoting.

As Keith and others have been asking you, please retain attribution
when quoting someone else's words.

And, please don't keep making hidden changes to followups. If you want
to change followups it would be a courtesy to state the change you
have made.

Warning to others: When replying to Jonathan you may like to check how
followups are set - i.e. what groups you are replying to. He changes
them without notice. For example, this thread was only in comp.lang.c.
Without warning anyone (and without posting to these groups himself)
he earlier added in followups to

comp.os.msdos.programmer, openwatcom.users.c_cpp

leading anyone who replied to him without checking to inadvertently
post to those groups. The confusion therefrom is what led to this
subthread. And he silently *replaced* all groups with followups to

news.newusers.questions

in the message I'm replying to. Hoping to catch me out, no doubt. As I
stated earlier, he plays around with headers. I think that's been
clearly demonstrated. QED!

James
 
B

Ben Bacarisse

Malcolm McLean said:
Nearly 400 posts to this thread later, and we still haven't quite
established that Seebs wrote a spurious first entry to his errata.

Obviously that is the top priority here. Let's not discuss the merits
or otherwise of the book itself until we have cleared up the meaning of
one phrase in a out-of-print edition cited on an old web page.

Why not read the book and tell us what you think of it? If you don't
want to buy it and your library does no have it you can at least review
the code for free. I would be more interested in you opinion of either
of those than of your opinion about Seebs's reading of the phrase "in
general".

<snip>
 
B

Ben Bacarisse

Malcolm McLean said:
You're parsing a file, eg a script file. You check for the "end of
script" token, for the sake of argument the word "END". However if
characters follow the "END" the script has a syntax error, which must
be reported. So chomping whitespace and checking for feof() is a
reasonable thing to do.

What happens if there is a read error? Without a code fragment it is
not possible to be definitive, but one reason why it is almost always
wrong to loop using feof is that you need extra code to deal with error
situations.

I can't see how checking for feof can be reasonable given the simplicity
of the more robust alternatives.
 
M

Morris Keesan

What happens if there is a read error? Without a code fragment it is
not possible to be definitive, but one reason why it is almost always
wrong to loop using feof is that you need extra code to deal with error
situations.

I can't see how checking for feof can be reasonable given the simplicity
of the more robust alternatives.

The only real use I've ever had for feof() is AFTER something like
fread(), getc(), etc. returns a "nothing was read" indicator (e.g. fgetc()
returns EOF, or fread() returns 0). EOF from fgetc() does not distinguish
between error and end-of-file, so it's reasonable to use either feof() or
ferror() to distinguish between those two cases:

while ( (ch = getchar()) != EOF ) /* do something with ch */;

if (feof(stdin))
/* process end of file */;
else
/* handle error */;

Whether one wants to write "if (feof(fp))" or "if (ferror(fp))" is a matter
of personal style and logic of the program.
 
N

Nick Keighley

I don't think "In general", as the opening phrase of a sentence, can
ever mean "always".

I still think it's a pretty misleading statement (schildt's that is).
It pretty well implies that non-2s complement systems can be ignored,
or at least that this is an important and interesting point. A more
insteresting point is that it ***hardly ever matters how numbers are
represented***

If we can't even agree on that, there's not much
point going on to erratum number two, where the issues are a bit more
subtle.

I find it amazing you weren't able to read such a short, clear (!)
document right to the end.
 
T

Tim Rentsch

Keith Thompson said:
pete said:
In Appendix A, Section 10, function definitions,
K&R1 has the sentence "Here int is the type-specifier;"
in reference to a complete example of a function definition.

The same part of K&R2 says
"Here int is the declaration specifier;".

I don't have my copies of K&R handy, but ...

Given
int foo(void) { /* ... */ }
int *is* the only type-specifier in sight. [snip]

Of course, you didn't mean that literally. Either that
or you're overdue for that eye exam. :)
 
K

Keith Thompson

Tim Rentsch said:
Keith Thompson said:
pete said:
Keith Thompson wrote:

I'll concede that some people refer to a function's return type
as the type of the function, and this can be fairly harmless in
informal discussions. But such usage is strictly incorrect, and
either using it in a C reference book or attempting to "correct"
someone who has used the terms correctly is just wrong.

In Appendix A, Section 10, function definitions,
K&R1 has the sentence "Here int is the type-specifier;"
in reference to a complete example of a function definition.

The same part of K&R2 says
"Here int is the declaration specifier;".

I don't have my copies of K&R handy, but ...

Given
int foo(void) { /* ... */ }
int *is* the only type-specifier in sight. [snip]

Of course, you didn't mean that literally. Either that
or you're overdue for that eye exam. :)

Yes, "void" is another type-specifier. And yes, I am overdue for that
eye exam (though I don't think that's relevant).
 
N

Nick

Willem said:
Nick wrote:
) Looking at these makes me realise that I don't think I've /ever/ used
) feof in my life. Trying to read until there is nothing more works so
) well.
)
) Does feof have a real use I've somehow missed (the examples above are
) clearly not it - they can all be improved by not using the function).

Well,

Euh...

As far as I know, no. I don't think I ever used it either.

Of course, I assume you *do* use ferror() to check for errors when you
get an EOF on a read. IIRC, the only two reasons you can get EOF is
when you either have an error (ferror()) or end of file (feof()).

I guess for robustness you could check both.

Feel free to correct me if I'm wrong here.

Well you're wrong that I don't systematically test for errors when I hit
end-of-file. If my system is hosed to the extent that my disk files
aren't reading properly, there isn't going to be a lot of error recovery
I can do anyway. But there are clearly other situations where this is
not as likely.
 
N

Nick

Richard Heathfield said:
Yes, it did.


It sure looks accurate to me.

I think it's time that you picked up a copy of the book (preferably
from the library or from a disgruntled C programmer's bin). Come back
when you've actually read the darn thing.

Drop me your address and I'll post you one (possibly asking for
something toward the posting costs). If we've stopped playing the game
I can't see any other use for it.
 
J

J de Boyne Pollard

Then you are mistaken.

But you are unable to provide a basis for that, or your
earlier assertion that the world is deluded, it seems. As
I said, M. McLean's choices are a false dichotomy. It's
quite easy to think of possibilities other than just the
two stated. Try it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top