Schildt

[Walter Banks]

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.

McGraw Hill bought several small publishing houses in the late 70's and 80's
to broaden their portfolio from a primarily business book and magazine
company. These acquisitions included a small California based company
owned by Adam Osborne that specialized in publishing style edited
spec sheets and annotated reference books. Osbournes acquisitions
included two of Schildt's controversial books on C.

"The Annotated ANSI C Standard" ISBN 0-07-881952-0 and
"C The complete reference" ISBN 0-07-212124-6 . Osborne's
company was set up as a wholly owned division of McGraw Hill after
McGraw Hill acquired its assets. Osborne is owned by McGraw Hill
although it didn't start out that way.

"The Annotated ANSI C Standard" (the muffin cover) is the Schildt
book that was reviewed by Clive Feather. This book reprints most
of the ANSI/ISO 9899-1990 standards document. (Note C90 not C99)
Many of Clive's comments simply compared the C90 text reprinted
in the book with Schildt's explanation on the opposite page. There
is no doubt about which version of C that Schildt was referring.
This was a book promoted as an annotated standard's document
like many of the other Osborne titles.

The cover of "C The complete reference" specifically refers to C99. This
title is often confused with the book that Clive Feather reviewed.



Regards,


w..

 

[Flash Gordon]

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

That imlies they actually tried, rather than either assuming or relying
on incorrect advice from someone else.

Using errno correctly is easy, but a lot of people have not been given
correct information and therefor do not know how to use it correctly.

 

[Dik T. Winter]

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

(You apparently mean "intersection of languages", I think.)

But this is a bit strange. What kind of language is the intersection of
Algol 60 and Algol 68? How do you determine the intersection of those
two languages? By looking at the syntax? But note that in Algol 68
'begin' 'bool' b; b := 1 'end'
contains a syntax error. (The assignment of '1' to 'b' is the syntax
error. The grammar can not produce that assignment in that context.)

 

[Dik T. Winter]

> "Dik T. Winter" <[email protected]> ha scritto nel messaggio
> news:[email protected]... ....
>
> if one PC has at last one 32bits data type, it is possible to return a
> variable that show 32 types of errors distinguishes from them example

I would think there would be quite a bit more. However, a function like
"fopen" returns a null pointer on error. Do you suggest more than a single
null pointer to distinguish the different types of error?

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> Unfortunately, errno doesn't work that way. No library function
> sets errno to zero, but most library functions can set it non-zero
> even if they succeed.

Yes, I know that. The design of errno is indeed "suboptimal". My argument
was only about not clearing it in library routines.

> In function loadImage: Not a typewriter

I do not think I want to count the number of times I have seen just such
an error messafe...

 

[Seebs]

Richard, Heathfield is making a false claim: that C can be implemented
without a runtime stack. He is speaking outside of his area of
competence. I am not because I'm right and he is wrong.

Uh.

Actually, no, he's right. There are stackless machines running C just fine.

.... I begin to see the sources of the neologism "nilgewater".

-s

 

[spinoza1111]

You need to cease the patronizing language, because it is a
deliberate, and very dishonest attempt to pose as an expert.

Richard, Heathfield is making a false claim: that C can be implemented
without a runtime stack. He is speaking outside of his area of
competence. I am not because I'm right and he is wrong.

Your Mercutio ("a plague on both your houses") act is wearisome
because in the old play, Tybalt was a thug who gets what's coming to
him.

 

[Nick Keighley]

spinoza1111 <[email protected]> writes:

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

if one PC has at last one 32bits data type, it is possible to return a variable
that show 32 types of errors distinguishes from them
example
0x0000_0000     right
0x0000_0001     1 error
0x0000_0002     2 error
0x0000_0004     3 error
0x0000_0008     4 error
....
if the problem is distinguish errors, so why use "errno"?
are they few?

then for find error i don't understand why someone has to use
the excepion handle

what's an "exception handle"

and stop the programme in one indefinite position

what does this mean?

 

[Nick Keighley]

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

(You apparently mean "intersection of languages", I think.)

But this is a bit strange.  What kind of language is the intersection of
Algol 60 and Algol 68?  How do you determine the intersection of those
two languages?  By looking at the syntax?  But note that in Algol 68
   'begin' 'bool' b; b := 1 'end'
contains a syntax error.  (The assignment of '1' to 'b' is the syntax
error.  The grammar can not produce that assignment in that context.)

just curious, why? Is assignment not allowed at that point or does the
grammer
not permit the assignment of 1 to a bool?

 

[Dik T. Winter]

>
> just curious, why? Is assignment not allowed at that point or does the
> grammer not permit the assignment of 1 to a bool?

The latter. From memory, the grammar reads something like (from memory):
MODE assignment : ref to MODE left_part ':=' MODE right_part
without the MODE's and the 'ref to' part is would be similar to simple a
simple grammar in BNF, but just those parts make it a 2-level van
Wijngaarden grammar that will produce 'b := 1' only if the MODE's are
identical or can be made identical by appropriate coercions. And '1'
can not be coerced to 'bool right_part'.

 

[Nick Keighley]

The charming thing about this particular food fight is that every
one is right.  The trick is that every one gets to use their own
definition of stack.  Part of the game is to assiduously ignore
the fact that the other chap is using a different definition.

I've tried injecting terms like "logical stack" and "contiguous
stack".

In summary because of the way C works automatic varaibles are
allocated
and freed in a LIFO manner. This also corresponds to the LIFO nature
of function calls. Hence memory for both can be managed in a LIFO
manner. If the underlying hardware provides support for a stack (as
most
modern hardware does) then it is convenient to use it. Some hardware
does
not directly support a stack but C can still be quite efficeintly
implemented on such machines. The C standard does not require a stack
though implementations will need to manage memory in a LIFO fashion.

I think telling beginners "automatic variables are allocated on the
stack"
is slightly misleading. I cannot swear I've never done it.

 

[Seebs]

In summary because of the way C works automatic varaibles are
allocated and freed in a LIFO manner.

Mostly.

I gave an example a recent thread on clcm of a case where this was, in
fact, arguably not the case.

Summary: In at least one MIPS ABI, there are registers which can be used
for automatic variables. Every function may use them, but if it uses them,
it must save them before using them, and restore them before returning.

But not every function MUST use them.

So you can have a circumstance where there are several intermediate function
calls with function arguments and automatic variables, where an overrun of
an automatic variable in one function trashes a variable from several
stack frames higher.

No violation of any spec, variables stored in a clearly-non-LIFO manner.

(And, let me tell you, a wonderful thing to try to track down in the middle
of a couple million lines of code with a two-digit number of hours left
before something is supposed to ship.)

-s

 

[Keith Thompson]

The charming thing about this particular food fight is that every
one is right. The trick is that every one gets to use their own
definition of stack. Part of the game is to assiduously ignore
the fact that the other chap is using a different definition.

No, not really. I've gone to considerable effort to distinguish
between the two meanings of "stack", and I've repeatedly acknowledged
that C does effectively require a "stack" in the sense of some kind
of LIFO data structure, but that it doesn't require a contiguous
hardware stack.

Those who have been arguing that C requires a stack have either
blurred the distinction or falsely claimed that C requires a
contiguous hardware stack.

 

[spinoza1111]

Mostly.

I gave an example a recent thread on clcm of a case where this was, in
fact, arguably not the case.

Summary:  In at least one MIPS ABI, there are registers which can be used
for automatic variables.  Every function may use them, but if it uses them,
it must save them before using them, and restore them before returning.

But not every function MUST use them.

So you can have a circumstance where there are several intermediate function
calls with function arguments and automatic variables, where an overrun of
an automatic variable in one function trashes a variable from several
stack frames higher.

No violation of any spec, variables stored in a clearly-non-LIFO manner.

(And, let me tell you, a wonderful thing to try to track down in the middle
of a couple million lines of code with a two-digit number of hours left
before something is supposed to ship.)

-s

At ASPLOS 1987, I could see an irrational hatred of the stack. It has
deep cultural roots: for one thing, it's based on a humanist model of
problem-solving in which a human being can delay solving an immediate
problem and solve a deeper problem: this is inimical to American
"Taylorist" industrial management in which the employee is directed to
solve single problems one at a time.

[No, I'm not schizophrenic, nor "ranting", nor a "conspiracy
theorist". Instead, I read books.]

For another, it isn't "hard" its "soft" and this produces psychosexual
anxiety.

For another, it was invented in Yourup.

I'm sure that MIPS kiddies rage to eradicate it. It is regarded as a
bottleneck wrt parallelism, the holy grail of RISC, although it need
not be (the answer being more stacks). And if your optimizer can do
enough global flow analysis to remove recursion and function calls
themselves, great.

But you could never, not in a million years, explain C sensibly after
such optimization, and Herb was trying to explain how C is supposed to
work!

 

[spinoza1111]

No, not really.  I've gone to considerable effort to distinguish
between the two meanings of "stack", and I've repeatedly acknowledged
that C does effectively require a "stack" in the sense of some kind
of LIFO data structure, but that it doesn't require a contiguous
hardware stack.

Nobody has said it does, Keith.

Those who have been arguing that C requires a stack have either
blurred the distinction or falsely claimed that C requires a
contiguous hardware stack.

No, we haven't. You've created confusion and you've been what you call
the troll.

 

[spinoza1111]

Whoever said this ran out of ideas and started hurling names. Grow up.
Nilges is not only my name, it's my father's name. He fought the good
fight for medical ethics. It's my uncle's name. He died in WWII. You
ever use that word to my face, you're gonna need a new set of teeth.

I've tried injecting terms like "logical stack" and "contiguous
stack".

In summary because of the way C works automatic varaibles are
allocated
and freed in a LIFO manner. This also corresponds to the LIFO nature
of function calls. Hence memory for both can be managed in a LIFO
manner. If the underlying hardware provides support for a stack (as
most
modern hardware does) then it is convenient to use it. Some hardware
does
not directly support a stack but C can still be quite efficeintly
implemented on such machines.  The C standard does not require a stack
though implementations will need to manage memory in a LIFO fashion.

I think telling beginners "automatic variables are allocated on the
stack"
is slightly misleading. I cannot swear I've never done it.- Hide quoted text -

Well you better not. You better stop children hey what's that sound...

 

[spinoza1111]

Uh.

Actually, no, he's right.  There are stackless machines running C just fine.

... I begin to see the sources of the neologism "nilgewater".

Oh, so you said it. OK, Peter:

1. Nilges is my father's name. He is now retired, but fought the good
fight as a physician for medical ethics and against nuclear war.

2. Nilges is my uncle's name. He died saying "follow me" as a captain
in the United States Army.

3. If you and I ever meet, and you use that word, you will be needing
a new set of teeth.

 

[spinoza1111]

The charming thing about this particular food fight is that every
one is right.  The trick is that every one gets to use their own
definition of stack.  Part of the game is to assiduously ignore
the fact that the other chap is using a different definition.

I find nothing charming here about people making neologistic insults
out of patronyms which embarass members of my family or Schildt's. I
find it adolescent, and coming from people in elite technical
positions, I am glad I've left programming and need not be beholden to
such adult children.

Nor would I say "a plague on both your houses". Thompson and Seebach
are denying that the abstract stack is necessary to execute C code,
and this is just false. They are insisting on it because they've so
libeled Schildt that they're afraid to recant even in part.

 

[osmium]

Nor would I say "a plague on both your houses". Thompson and Seebach
are denying that the abstract stack is necessary to execute C code,
and this is just false. They are insisting on it because they've so
libeled Schildt that they're afraid to recant even in part.

WTF are you talking about? Keith Thompson has said no such thing. You are
just plain making shit up. The only thing that makes sense here is to
boycott this thread.

 

[Kenny McCormack]

No, we haven't. You've created confusion and you've been what you call
the troll.

And this is where, by rights, I should be admonishing you to stop
feeding the troll(s).

But I won't, because these trolls (Dicky & Kiki) are so much fun to
watch and parody.