Schildt

[vippstar]

Learners often misunderstand this point and you are contributing to
the misinformation by repeating the error.  Using errno correctly is
not hard when you know how it works, but lots of books and tutorials
seem to get it wrong.

'X isn't hard, but a lot find it to be'.

 

[Phil Carmody]

Since "Spinoza" appeared here, I have started to ponder if all this
hate against Schildt by the regulars wouldn't be maybe just a character
assasination like they love to do.

So I started looking for critics to Schildt and found

http://www.lysator.liu.se/c/schildt.html

There, I can read:
<quote>
3.14

## An object is either a variable or a constant that resides at a
## physical memory address.

In C, a constant does not reside in memory, (except for some string
literals) and so is not an object.
<end quote>

This is completely wrong. Outside some constants that are inlined by the
compiler because the processor supports inlined constants, all other
constants are just like a character string.

For instance in a x86 implementation:

double a = 12.345;

The double constant 12.345 will reside in memory.

[snip]

And in an x86 implementation
double a = 1.0, b=0.0;
The double constants 1.0 and 0.0 need not ever reside in memory.

That doesn't make it an "object" as the C standard defines the term.

Zachary.

Phil

 

[Phil Carmody]

Or about its support for characters wider than 8 bits. (For example,
on some DSPs CHAR_BIT is 16 or even 32.)

The classic "take the piss out of DSP" example is the 24bit char.
Out of the non-8-bit char possibilities, that's the only one I have
actually programmed for. (In C.)

Phil

 

[Chris H]

Great. Obviously Feather is pedantically right, but is it very important?

Yes. It can be fatal in embedded systems. You know, the ones that
control life: Aircraft, medical equipment, elevators, air-con, security
systems, power stations. You need precision and precise behaviour.

BTW I know Clive personally and I have never found him to be wrong when
it comes to precision in the C language.

 

[John Bode]

Since "Spinoza" appeared here, I have started to ponder if all this
hate against Schildt by the regulars wouldn't be maybe just a character
assasination like they love to do.

My personal animosity towards Schildt stems from buying an early
edition of his C reference and discovering that the bulk of the sample
code was riddled with logic errors of this caliber:

fclose(file);
fprintf(file, ...);

Never mind his attitude that C was whatever Microsoft defined it to
be, so his samples had to be extensively edited to run on other
platforms. I am convinced that the popularity of his books and the
generally poor quality of C code written in the '90s (especially for
the DOS/Windows platform) are correlated. Even today the bulk of his
works are "not recommended" by groups like the ACCU.

I am sure his current output is better than what he released 20 years
ago (dear God I hope so), but what he released 20 years ago was pretty
goddamned awful.

Yes, some of Feather's criticisms are weak. The bulk of them are not,
and he details several places where Shildt's explanation of the text
in the standard is simply *wrong*, on the order of the standard says
the sky is blue, and Schildt explains it as the sky is mauve.

 

[Dik T. Winter]

>
> Of course there are. So what's the use of errno?

To enable the programmer to distinguish between different ways of failures?

The model simply is: if there is an error, the function returns a value
that must be interpreted as an error. If there is more than one single
error possible, errno distinguishes between the different ways.

 

[Dik T. Winter]

>
> It is a very poor mechanism by modern standards, but it is made worse
> than it need be by misinformation about its use. It would not be
> improved by having it set to zero by every library function

No, it is actually good design to make error conditions sticky. Otherwise
how would you be able to detect an error when library functions call other
library functions? Sticky error conditions mean that between the last time
you cleared it and the time you check it, if there has been an error in
between, you will see it. There was a good reason IEEE made the error
flags on floating-point arithmetic sticky.

 

[Ben Bacarisse]

No, it is actually good design to make error conditions sticky.

Are we not agreeing here? I am arguing against spinoza1111's
suggestion that errno should be cleared by library functions.

Otherwise
how would you be able to detect an error when library functions call other
library functions? Sticky error conditions mean that between the last time
you cleared it and the time you check it, if there has been an error in
between, you will see it.

Is that not how errno behaves? Is that not the behaviour I was
supporting?

Where the use of errno is not document by the standard it can be set
non-zero by library functions which complicates the portability of
checking the value across multiple calls, but it is still "sticky"
just not sticky only to standard defined usages.

 

[spinoza1111]

In <[email protected]>,

spinoza1111wrote:


You frequently try to mask your mistakes with such fluff, but it won't
wash this time any more than it usually does. Here's why:

Clive Feather's critique was of Schildt's "Annotated C Standard". If
the annotations flatly contradict the Standard, then the annotations
are erroneous. Schildt's claim: "If errno is zero, then no error has
been detected" is simply false. Literary genres have nothing to do
with it. If Schildt wants to write novels, fine, let him write
novels. But if he's annotating the C Standard, he ought to get the
annotations right.


Schildt's annotations were of C90, not C99.



Here are the names of a few of the people who developed the original C
Standard, the people you are accusing of incompetence:

Jim Brodie (co-author with P J Plauger of "ANSI and Iso Standard C
Programmer's Reference" and "Standard C")
Doug Gwyn and David Prosser (both in K&R2's attaboy list)
Samuel Harbison (co-author of a C reference book)
Larry Jones (posts here)
P J Plauger (author of Whitesmith C, vendor of the C and C++ libraries
that ship with Visual C++, co-author with Jim Brodie);
Thomas Plum (of Plum Hall - among other things they do conformance
validation).

Lots of others, but those seemed to me to be the ones you are most
likely to have heard of. At least two of the above are active on
Usenet, one of them in this very group.

You are in no position to pass judgement on the competence of the C
committee. It wasn't that long ago that you had to have sequence
points explained to you. It was very recently indeed that we had to
explain to you (several times, since you're slow of thinking and
didn't get it at first) that C is call-by-value. You don't know spit
about C. Leave judgements of competence to the competent.

In actuality, you are merely reminding me of what I knew when I
learned C in the late 1980s, taught C at Princeton, and assisted Nash
with C. You need to cease the patronizing language, because it is a
deliberate, and very dishonest attempt to pose as an expert. I predict
it's going to get you in legal trouble.

I am well aware that in "banks and insurance companies" a form of
employee discipline, popular in your nook-shotten isle since Victorian
times, has been the anti-intellectualism of pretending that within the
counting-house, the drudges have their own "expertise" and can
therefore take the piss of any upstart who's completed grammar
school.

But it merely makes you a character out of Dickens.

You're not competent. You believe it's possible to craft a C runtime
without using stacks, and I've shown you that this is like squaring
the circle. Schildt and Navia have used C to develop a C compiler and
this means that Navia is the authority here, not you. I will also ask
Schildt, with whom I have had private communication (he thanked me for
fixing his wikipedia biography) to join us, and hopefully end your
destructive use of this facility.

I hope to rehabilitate you and make you a good contributor. But first
you must learn real manners, which do not consists in the alternation
of fawning like Uriah Heep, and destructive enabling.

From the C Rationale: "The error reporting machinery centered about
the setting of errno is generally regarded with tolerance at best.  
It requires a ``pathological coupling'' between library functions and
makes use of a static writable memory cell, which interferes with the
construction of shareable libraries.  Nevertheless, the Committee
preferred to standardize this existing, however deficient, machinery
rather than invent something more ambitious."

Sure. That'd break compilers, and compiler development companies would
have to hire people to fix them. Seebach's mission was to preserve
their profits, because in the Bush-Clinton era, and today, job one in
America and the G-8 is making sure the rich stay rich.

They pretend to an unearned scientific asceticism but the motivation
is obvious.

 

[spinoza1111]

Yes.  It can be fatal in embedded systems.  You know, the ones that
control life: Aircraft, medical equipment, elevators, air-con, security
systems, power stations.  You need precision and precise behaviour.

Fine words, but precision isn't always the answer. The American writer
on the air transport industry, William Langiewiesche, described an
accident in the New Yorker in which two airplanes recently collided
over south America. Computer control of airspace had precisely put
them too close together.

And, of course, there's the false precision of having loads o' digits
in floating point, something Dan McCracken addressed years ago in
Numerical Methods and Fortran Programming but which TI 83 kiddies
still don't get.

Actually, "precision" fails. Truth on the other hand works all the
time by definition. Entirely too many engineers, and mere programmers
who fantasize that they are engineers, especially for some reason from
Nordic countries or of Nordic ethnicity, think that if they are
precise, they are true and good. But cf Edwin Black, IBM and the
Holocaust.

 

[Chris M. Thomasson]

[...]

Seebach's mission was to preserve their profits, because
in the Bush-Clinton era, and today, job one in America
and the G-8 is making sure the rich stay rich.

Ill gotten gains aside for a moment, I sure do hope that an honestly "rich"
woman/man can maintain her/his wealth throughout their lifetime!

 

[spinoza1111]

[...]

Seebach's mission was to preserve their profits, because
in the Bush-Clinton era, and today, job one in America
and the G-8 is making sure the rich stay rich.

Ill gotten gains aside for a moment, I sure do hope that an honestly "rich"
woman/man can maintain her/his wealth throughout their lifetime!

....abstractions, like flesh-eating vampire zombies, overcome reality:
you're marshaled into defending an abstract, imaginary rich man who
has an abstract, and therefore unquestionable, right to his gains, and
to evade taxes. Of course, the reality is that the wealth generated by
not having to hire a compiler developer to change a compiler to be
compliant to a truly useful standard is a tranche of wealth that is
shared by many people, in a massively unequal and normally unfair way.

During the 2008 election, "Joe the Plumber" defended not his rights as
a plumber's helper making 40,000 per year, but as the fictional,
imaginary owner of a plumbing company.

 

[Chris M. Thomasson]

[...]

Seebach's mission was to preserve their profits, because
in the Bush-Clinton era, and today, job one in America
and the G-8 is making sure the rich stay rich.

Ill gotten gains aside for a moment, I sure do hope that an honestly
"rich"
woman/man can maintain her/his wealth throughout their lifetime!

...abstractions, like flesh-eating vampire zombies, overcome reality:
you're marshaled into defending an abstract, imaginary rich man who
has an abstract, and therefore unquestionable, right to his gains, and
to evade taxes.

IMVHO, a honest rich man does have an unquestionable right to be rich. If
she/he fails to pay taxes, then, well, they should be thoroughly subjected
to the proper consequences.

Of course, the reality is that the wealth generated by
not having to hire a compiler developer to change a compiler to be
compliant to a truly useful standard is a tranche of wealth that is
shared by many people, in a massively unequal and normally unfair way.

During the 2008 election, "Joe the Plumber" defended not his rights as
a plumber's helper making 40,000 per year, but as the fictional,
imaginary owner of a plumbing company.

I sure do hope that Joe can eventually acquire a successful plumbing company
and become rich well beyond his dreams.

:^)

 

[Chris M. Thomasson]

[...]

Seebach's mission was to preserve their profits, because
in the Bush-Clinton era, and today, job one in America
and the G-8 is making sure the rich stay rich.

Ill gotten gains aside for a moment, I sure do hope that an honestly
"rich"
woman/man can maintain her/his wealth throughout their lifetime!

...abstractions, like flesh-eating vampire zombies, overcome reality:
you're marshaled into defending an abstract, imaginary rich man who
has an abstract, and therefore unquestionable, right to his gains, and
to evade taxes.

IMVHO, a honest rich man does have an unquestionable right to be rich.

That should probably read as:


IMVHO, ANY honest man has an unquestionable right to be rich.

 

[Ben Bacarisse]

IMVHO, a honest rich man does have an unquestionable right to be
rich. If she/he fails to pay taxes, then, well, they should be
thoroughly subjected to the proper consequences.

Thread topics do drift, but I suggest this one has lurched! Please
consider topicality when replying.

<snip>

 

[spinoza1111]

In

spinoza1111wrote:



No, you've just shown that you haven't got a clue.


More precisely, Schildt has developed an *interpreter* that *attempts*
to implement a *subset* of what he *believes* to be C, and Navia has
taken the source code of an existing compiler and modified it - by
his own admission it doesn't conform to C90 (and he has no intention
of making it conform) and according to the latest information I have
it doesn't conform to C99 either, so it isn't really a C compiler at
all (yet).

We've already discovered here that C is a set of languages: but in
formal language theory, whose usage we should follow, a union or
intersection of a language is a language. C is neither K&R, nor is it
C89, nor is it C99. It is all of those things. There is nothing wrong
with this as long as you understand that a "language" as opposed to a
"protocol" or a mathematical formalism can be self-contradictory or
fuzzy, but you probably don't.

If you choose to pay more attention to Jacob Navia's advice on C than
to mine, that's entirely up to you.

Damn straight. And you can start respecting other people's freedom in
a substantive manner by leaving this group, since you're unable to
behave yourself.

Bring him on. We can ask him when he's going to publish errata for all
those bugs in his books.

Books don't have bugs: software does. As I have already told you, no
qualified programmer would ever blindly key in code examples in a book
without testing them, and modifying them as needed according to
compiler diagnostics and unexpected results. Read the front matter: no
warranty, express or implied. Like actual software, Schildt, McGraw
Hill and indeed your publisher is protected by this exemption to the
US commercial code and its British equivalent. While in software it
can be argued that users deserve more protection, the First Amendment
in the USA, and British constitutional law in your country, gives wide
leeway to the authors of books to express things as they see fit.

If you like, although being a moron you probably don't, the teacher of
programming has to use poetry to help his student understand: he needs
to speak metaphorically and tell stories that in terms of an
international standard are false. Because you, Feather and Schildt are
techies, you fail utterly to understand this.

 

[osmium]

Books don't have bugs: software does. As I have already told you, no
qualified programmer would ever blindly key in code examples in a book
without testing them, and modifying them as needed according to
compiler diagnostics and unexpected results. Read the front matter: no
warranty, express or implied. Like actual software, Schildt, McGraw
Hill and indeed your publisher is protected by this exemption to the
US commercial code and its British equivalent. While in software it
can be argued that users deserve more protection, the First Amendment
in the USA, and British constitutional law in your country, gives wide
leeway to the authors of books to express things as they see fit.

This is awful! I had no idea that the publisher for Schildt books was
McGraw-Hill. McGraw-Hill used to be a highly respected publisher of college
level textbooks and I learned much of what I know from McGraw-Hill books.
The Schldt books I have seen don't even pass the giggle test for an
authoritative book. Somebody *really* dropped the ball on this one.

 

[Lew Pitcher]

In


Programs can have bugs. Books (about programming) can have programs.
Therefore, books can have bugs.

For that matter, books have erratta, which are corrections to bugs in the
orignal book (for a liberal-enough definition of bug).

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[spinoza1111]

In

spinoza1111wrote:


Programs can have bugs. Books (about programming) can have programs.
Therefore, books can have bugs.

Doesn't follow, because books about programming do not "have"
programs, as books.

A book can contain a CD containing a program. But the CD is extra
material, not part of the book.

None of the code examples that Herb wrote were presented as turnkey
software.

Furthermore, you're shooting youself in the foot. Feather and Seebach
claim Herb is wrong about C, not that he deliberately ships bad
software while saying it's good. Having been shown wrong, you are now
grasping at straws, claiming that Herb's book "has bugs".

Books have paper. Therefore books are made of wood. Of course, this is
nonsense. As a book author, Schildt was doing the best job he could to
get programmers started with C. McGraw Hill probably chose to spin the
book as C99 aware because of the ongoing standards effort. Herb's main
concern, however, was to introduce programmers to C, since his
audience was using a range of compliant and noncompliant compilers.

 

[spinoza1111]

In

spinoza1111wrote:



No, you've just shown that you haven't got a clue.


More precisely, Schildt has developed an *interpreter* that *attempts*
to implement a *subset* of what he *believes* to be C, and Navia has
taken the source code of an existing compiler and modified it - by
his own admission it doesn't conform to C90 (and he has no intention
of making it conform) and according to the latest information I have
it doesn't conform to C99 either, so it isn't really a C compiler at
all (yet).


If you choose to pay more attention to Jacob Navia's advice on C than
to mine, that's entirely up to you.


Bring him on. We can ask him when he's going to publish errata for all
those bugs in his books.

<nonsense snipped>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

He's probably unwilling, for the same reason Kernighan won't post to
this intellectual slum.