Schildt

[jacob navia]

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.

Why?

Because the machine doesn't support inlined floating point constants!

The same for long double constants, for structures initialized by
constants, for 64 bit constants, etc etc.

All those constants must be LOADED into their correct places by
the compiler. This happens automatically so for the user in high
level C it *looks* like they aren't there. That is WRONG though.

They reside on memory.


The only exceptions are constants that the processor accepts as
part of the instruction. For instance, the x86 accepts integers
up to 32 bits as immediate constants available in the instructions
themselves.

The power PC processor accepts constants up to 16 bit only. All other
integers must be loaded, the same as floating point data.


Conclusion:

The only constants that are initialized inline are the inlined constants
accepted inline by the processor (in the code stream)

Schild is right and Mr Feather (that I respect of course) is wrong.

Mainly the other criticism are matters of style, where Mr Feather
differs from Mr Schildt. He would have more explained about the
standard, more precise stuff, etc.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Maybe. This is a matter of style, and doesn't justify the attacks
that are given here.

 

[vippstar]

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:

Here's a hint for you: "In C [...]" and "in a x86 implementation
[...]" is not the same.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Oh, I can do this too:
You're pedantically right, but is it very important? No it's not,
therefore your pedantic point is dismissed and Feather is right.

 

[jacob navia]

vippstar a écrit :
And of course you snipped the part where I wrote about the Power PC.

THEN (after snipping the power pc part) you doctor me:

> Here's a hint for you: "In C [...]" and "in a x86 implementation
> [...]" is not the same.
>

I wasn't speaking about C code but the assembly code C generates with
the help of a compiler. In that code, constants are NOT inlined unless
the processor accepts them inlined. So, to demonstrate my point I used
two processors:

power PC and x86. You snipped the power PC part and then
you doctor me that I speak only about the x86.

Nice isn't it?

 

[Keith Thompson]

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]

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

A "constant that resides at a physical memory address" is not a C
object. I suspect (without proof) that Schildt was thinking of the
const keyword, which is very different from a "constant". For example:

int x = 42;
const int y = 43;

Both x and y are objects, though (depending on how you define
the term) only x is a "variable". If this is what Schildt meant,
he should have said so.

If he really meant to discuss the fact that some constants, such as
12.345 in your example, may be stored in memory, that's an irrelevant
implementation detail that doesn't belong in a book calling itself
"The Annotated C Standard", at least not without an acknowledgement
that it's implementation-specific.

Perhaps Clive Feather's correction could have been better worded
(I think he overlooked the obvious interpretation that Schildt had
confused "constant" with "const), but the fact remains that Shildt
got this wrong.

 

[spinoza1111]

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

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:

Here's a hint for you: "In C [...]" and "in a x86 implementation
[...]" is not the same.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Oh, I can do this too:
You're pedantically right, but is it very important? No it's not,
therefore your pedantic point is dismissed and Feather is right.

No, Feather is the pedant, since knowledge (cf Hellenistic philosophy,
Martha Nussbaum, Adorno, elsewhere) is that which contributes to human
survival and flourishing. Sure, pure mathematical knowledge which does
not seem at first glance to be about survival and flourishing is
knowledge: but it's "useless" knowledge which forms a part of a larger
whole that is independent of our minds. And, "useless" knowledge in
pure mathematics (such as the complex number of the 19th century)
often turns out to have a physical (here, quantum theoretic) use after
all!

But C, especially C99, is a man-made artifact running on enormous
automata which in the last analysis, sub specie aeternitatis, are
nothing more than finite automata (because their memory is finite if
large). Therefore if we may define "pedantry" as true knowledge that
does not in any significant way contribute to human survival and
flourishing, or form a part of that which so contributes (as does
math), then Feather is a pedant qed.

What contributes to human survival and flourishing? Well, Herb's books
because they help people keep their jobs in a society run by pigs.

Thank you for your attention.

- Hide quoted text -

 

[spinoza1111]

vippstar a écrit :

And of course you snipped the part where I wrote about the Power PC.

THEN (after snipping the power pc part) you doctor me:

 > Here's a hint for you: "In C [...]" and "in a x86 implementation
 > [...]" is not the same.
 >

I wasn't speaking about C code but the assembly code C generates with
the help of a compiler. In that code, constants are NOT inlined unless
the processor accepts them inlined. So, to demonstrate my point I used
two processors:

power PC and x86. You snipped the power PC part and then
you doctor me that I speak only about the x86.

Nice isn't it?

Welcome to hell. Bienvenue a l'enfer.

 

[spinoza1111]

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.

Why?

Because the machine doesn't support inlined floating point constants!

The same for long double constants, for structures initialized by
constants, for 64 bit constants, etc etc.

All those constants must be LOADED into their correct places by
the compiler. This happens automatically so for the user in high
level C it *looks* like they aren't there. That is WRONG though.

They reside on memory.

The only exceptions are constants that the processor accepts as
part of the instruction. For instance, the x86 accepts integers
up to 32 bits as immediate constants available in the instructions
themselves.

The power PC processor accepts constants up to 16 bit only. All other
integers must be loaded, the same as floating point data.

Conclusion:

The only constants that are initialized inline are the inlined constants
accepted inline by the processor (in the code stream)

Schild is right and Mr Feather (that I respect of course) is wrong.

Mainly the other criticism are matters of style, where Mr Feather
differs from Mr Schildt. He would have more explained about the
standard, more precise stuff, etc.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Maybe. This is a matter of style, and doesn't justify the attacks
that are given here.

The standards boys had a problem, Monsieur Navia. It was that the next
generation of languages (Java and .Net among them) do a better job
than C at hiding the width of characters, therefore a programmer can
write code which accepts characters with values beyond 255 without
doing anything.

Whereas the C programmer has to investigate UCHAR_MAX, add it, and
make sure that none of his code aliases characters in such a way as to
make his expressions depend on bit width. Not only does he have to
define it (or #include code that defines it), he also has to be
conscientious enough to use it,and neither 8 nor 16, in such
expressions.

Of course, Richard and Keithie boy thinks this builds character in the
Anglo-Saxon register, toughening them up like your Marechal Petain's
"group hikes and singing".

But, mais non, it does nothing of the sort. In the old days such
crotchets, such inconvenient convenience, produced ratlike,
ferretlike, furtive, skinny little creeps with personality disorders
who smoked themselves into an early grave. Today it produces Fat
Bastards, because their "discipline" is a metaphorical shadow, a
penumbra.

Therefore Feather rebukes Schildt for lettin' the cat out of the bag:
C effectively binds the programmer to 8 bit characters.

 

[spinoza1111]

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.

Why?

Because the machine doesn't support inlined floating point constants!

The same for long double constants, for structures initialized by
constants, for 64 bit constants, etc etc.

All those constants must be LOADED into their correct places by
the compiler. This happens automatically so for the user in high
level C it *looks* like they aren't there. That is WRONG though.

They reside on memory.

The only exceptions are constants that the processor accepts as
part of the instruction. For instance, the x86 accepts integers
up to 32 bits as immediate constants available in the instructions
themselves.

The power PC processor accepts constants up to 16 bit only. All other
integers must be loaded, the same as floating point data.

Conclusion:

The only constants that are initialized inline are the inlined constants
accepted inline by the processor (in the code stream)

Schild is right and Mr Feather (that I respect of course) is wrong.

Mainly the other criticism are matters of style, where Mr Feather
differs from Mr Schildt. He would have more explained about the
standard, more precise stuff, etc.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Maybe. This is a matter of style, and doesn't justify the attacks
that are given here.

Check this one out, Jacob.

7.1.4
Schildt: ## If errno is zero, then no error has been detected.

Feather: This isn't true at all. No library function will ever set
errno to zero, but if it is zero before one is called, it can remain
zero even if an error does occur.


Schildt is helping the programmer, but Feather creates confusion.

Programmers need to check error numbers, and in any number of systems,
zero has meant "OK, no problem".

Feather is just wrong if he things that "no library function will ever
set errno to zero". When, in PL/I or Visual Basic, I've written a
"library function", I sure as hell won't leave errno to chance. In C,
the library function should probably contain this code as its return
when nothing is broken:

errno = 0; return [ <something> ];

Or, I might define an errno in C Sharp like this:

int intErrNumber = 0;

Feather is saying that the Holy Standard permits library functions to
generate errors ** without telling a soul **, because existing
compilers from vendors do this, and the Standard was engineered to
make existing compilers from powerful vendors correct!

He's not only defending corporate profits without getting paid, he's
also destroying a reputation for shits and giggles!

He's also blessing extraordinarily poor practice.

In the 1960s, incompetents would write code that used subroutines
without checking return codes. In the 1970s as part of the overall
structured programming revolution, people learned to do this. To
defend corporate profits, Feather wants programmers to code like they
did in the 1960s: carelessly and in ignorance.

 

[spinoza1111]

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.

Why?

Because the machine doesn't support inlined floating point constants!

The same for long double constants, for structures initialized by
constants, for 64 bit constants, etc etc.

All those constants must be LOADED into their correct places by
the compiler. This happens automatically so for the user in high
level C it *looks* like they aren't there. That is WRONG though.

They reside on memory.

The only exceptions are constants that the processor accepts as
part of the instruction. For instance, the x86 accepts integers
up to 32 bits as immediate constants available in the instructions
themselves.

The power PC processor accepts constants up to 16 bit only. All other
integers must be loaded, the same as floating point data.

Conclusion:

The only constants that are initialized inline are the inlined constants
accepted inline by the processor (in the code stream)

Schild is right and Mr Feather (that I respect of course) is wrong.

Mainly the other criticism are matters of style, where Mr Feather
differs from Mr Schildt. He would have more explained about the
standard, more precise stuff, etc.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Maybe. This is a matter of style, and doesn't justify the attacks
that are given here.

Schildt: 7.1.3
## Frankly, many C programmers are not aware of the rules described
## in this section.

Feather: Quite right ! Unfortunately, the chance to explain the rules
was missed.


Unethically and dishonestly, Feather numbers his points to increase
their throw-weight. Many of them are smartassed remarks.

 

[spinoza1111]

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.

Why?

Because the machine doesn't support inlined floating point constants!

The same for long double constants, for structures initialized by
constants, for 64 bit constants, etc etc.

All those constants must be LOADED into their correct places by
the compiler. This happens automatically so for the user in high
level C it *looks* like they aren't there. That is WRONG though.

They reside on memory.

The only exceptions are constants that the processor accepts as
part of the instruction. For instance, the x86 accepts integers
up to 32 bits as immediate constants available in the instructions
themselves.

The power PC processor accepts constants up to 16 bit only. All other
integers must be loaded, the same as floating point data.

Conclusion:

The only constants that are initialized inline are the inlined constants
accepted inline by the processor (in the code stream)

Schild is right and Mr Feather (that I respect of course) is wrong.

Mainly the other criticism are matters of style, where Mr Feather
differs from Mr Schildt. He would have more explained about the
standard, more precise stuff, etc.

For instance Schildt says:

this limits the total character set to 255 characters.

and Feather criticises:

Actually, it limits it to UCHAR_MAX characters, which is at least 255,
but can be more.

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

Maybe. This is a matter of style, and doesn't justify the attacks
that are given here.

6.5
## In simple language, a declarator is the name of the object being
## declared.

In real C, a declarator is everything about the type and name of the
object except the basic type and storage class. For example, in
"static int *p[5];", the declarator is "*p[5]", and includes the
concepts of pointer, array, and size of array as well as the name.


Hey Clive [Feather]! What part of "in simple language" do you not
understand?

In terms of logic, C's declaration syntax (which is just bizarre)
makes a distinction between external and internal predicates,
primarily, I'd wot, to show off how smart little Dennis was.

The name of the thing above is NOT "p". It is "the array p which hath
five elements where p when derefed turns out to be an integer array in
static memory". Little Dennis didn't have the common sense to express
the pointerhood as a modification to int, and we have to live with
this.

The declarator is a name which contains facts about the thing, like
"Thor son of Ragnarok". "p" is a nickname. You can use the
preprocessor to clean up this mess:

#define addressOfInt int *
#define P p[5]
static addressOfInt P;

Please don't do this, but note that the smartest C programmers take
one look at C and resolve to create another language, using C.

Oh say can you C
Me no have use C
Me write compiler
For better way today
Me free now of C
Me very happy

But, in simple language, you need to walk before you can run, and most
declarations are a simple name.

Dijsktra found software as a field to be globally dishonest and was
able to escape. The rest of us need simple explanations of complex
mistakes which corporate power has cast in concrete. Most programmers
of the sort Herb was addressing don't get to write clean new code, and
if they do, they need to use Java or CSharp. They are maintaining
messes, and they need to get started. Herb succeeded in helping the
actual programmer. He didn't try to enable compiler development
companies to avoid having to change their compilers.

 

[Dik T. Winter]

> Feather is just wrong if he things that "no library function will ever
> set errno to zero".

No, in C he is *not* wrong.

> Feather is saying that the Holy Standard permits library functions to
> generate errors ** without telling a soul **, because existing
> compilers from vendors do this, and the Standard was engineered to
> make existing compilers from powerful vendors correct!

You are making this up. There are more ways to tell about errors than
setting errno. Consider returning an error value as function result.

 

[Ben Bacarisse]

[There is some misinformation about C here so I venture to reply]

The standards boys had a problem, Monsieur Navia. It was that the next
generation of languages (Java and .Net among them) do a better job
than C at hiding the width of characters, therefore a programmer can
write code which accepts characters with values beyond 255 without
doing anything.

Whereas the C programmer has to investigate UCHAR_MAX, add it, and
make sure that none of his code aliases characters in such a way as to
make his expressions depend on bit width. Not only does he have to
define it (or #include code that defines it), he also has to be
conscientious enough to use it,and neither 8 nor 16, in such
expressions.

Therefore Feather rebukes Schildt for lettin' the cat out of the bag:
C effectively binds the programmer to 8 bit characters.

No, it does not. You obviously don't know about C's support for wide
and multi-byte characters.

Do you have a recent copy of Schildt's "C: The Complete Reference"?
It should discuss C99's support for wide characters and multi-byte
encodings. It would be a serious flaw (in the most recent edition) if
your claim about it were true, but I doubt that he implies any such
thing (that C binds the programmer to 8 bit characters).

It would be ironic indeed for you to have found the most serious
criticism of the book to date but, as I say, I do not believe such an
omission is plausible.

 

[Ben Bacarisse]

6.5
## In simple language, a declarator is the name of the object being
## declared.

In real C, a declarator is everything about the type and name of the
object except the basic type and storage class. For example, in
"static int *p[5];", the declarator is "*p[5]", and includes the
concepts of pointer, array, and size of array as well as the name.

[The above is spinoza1111 quoting Clive Feather on Herbert Schildt.]

Hey Clive [Feather]! What part of "in simple language" do you not
understand?

In terms of logic, C's declaration syntax (which is just bizarre)
makes a distinction between external and internal predicates,
primarily, I'd wot, to show off how smart little Dennis was.

The name of the thing above is NOT "p". It is "the array p which hath
five elements where p when derefed turns out to be an integer array in
static memory".

You've got the type wrong, but that is a detail. p is an array whose
elements are pointers.

Little Dennis didn't have the common sense to express
the pointerhood as a modification to int, and we have to live with
this.

The declarator is a name which contains facts about the thing, like
"Thor son of Ragnarok". "p" is a nickname.

Are you claiming that Schildt wants his readers to think of "*p[5]" as
a name? That does not seem like a helpful use of language. It is
more likely, surely, that the phrase is an over-simplification. Maybe
he goes on to describe more complex declarators later (I don't have
the book).

<snip>

 

[spinoza1111]

6.5
##  In simple language, a declarator is the name of the object being
##  declared.

In real C, a declarator is everything about the type and name of the
object except the basic type and storage class.  For example, in
"static int *p[5];", the declarator is "*p[5]", and includes the
concepts of pointer, array, and size of array as well as the name.

[The above isspinoza1111quoting Clive Feather on Herbert Schildt.]

Hey Clive [Feather]! What part of "in simple language" do you not
understand?

In terms of logic, C's declaration syntax (which is just bizarre)
makes a distinction between external and internal predicates,
primarily, I'd wot, to show off how smart little Dennis was.

The name of the thing above is NOT "p". It is "the array p which hath
five elements where p when derefed turns out to be an integer array in
static memory".

You've got the type wrong, but that is a detail.  p is an array whose
elements are pointers.

Thanks for this professional correction.

Little Dennis didn't have the common sense to express
the pointerhood as a modification to int, and we have to live with
this.

The declarator is a name which contains facts about the thing, like
"Thor son of Ragnarok". "p" is a nickname.

Are you claiming that Schildt wants his readers to think of "*p[5]" as
a name?  That does not seem like a helpful use of language.  It is
more likely, surely, that the phrase is an over-simplification.  Maybe
he goes on to describe more complex declarators later (I don't have
the book).

He says "in simple language" which implies that what he's going to say
is not the whole truth.

 

[spinoza1111]

[There is some misinformation about C here so I venture to reply]

The standards boys had a problem, Monsieur Navia. It was that the next
generation of languages (Java and .Net among them) do a better job
than C at hiding the width of characters, therefore a programmer can
write code which accepts characters with values beyond 255 without
doing anything.

Whereas the C programmer has to investigate UCHAR_MAX, add it, and
make sure that none of his code aliases characters in such a way as to
make his expressions depend on bit width. Not only does he have to
define it (or #include code that defines it), he also has to be
conscientious enough to use it,and neither 8 nor 16, in such
expressions.

Therefore Feather rebukes Schildt for lettin' the cat out of the bag:
C effectively binds the programmer to 8 bit characters.

No, it does not.  You obviously don't know about C's support for wide
and multi-byte characters.

And you don't know encapsulation. You accept a "powerful" language
which wastes your discipline because it's power means you need to
diligently check too many details, which causes C programmers to
neglect more useful activities.

Do you have a recent copy of Schildt's "C: The Complete Reference"?
It should discuss C99's support for wide characters and multi-byte
encodings.  It would be a serious flaw (in the most recent edition) if
your claim about it were true, but I doubt that he implies any such
thing (that C binds the programmer to 8 bit characters).

He doesn't say this and neither do I. The problem isn't that C binds
the programmer to 8 bit characters: the problem is that by default it
does.

 

[spinoza1111]

In

spinoza1111wrote:



No, he's exactly right. "The value of errno is zero at program
startup, but is never set to zero by any library function." - C89
4.1.3, identical wording in C99 7.5(3).

You don't know the difference between two literary genres. One is
writing a computer book, the other is writing a standard.

The standard legislates what may be called C99. It is interpreted by
mere mortals by "language lawyers" in the same way as lawyers tell
clients the law.

It wouldn't surprise me, given the incompetence of the standard, if it
actually forbid library routines from zeroing errno. But I find it
hard to believe.

But if errno is global wrt all library functions, the Standard casts
an extraordinarily poor design in concrete on behalf of compiler
vendors.

 

[spinoza1111]

...
 > Feather is just wrong if he things that "no library function will ever
 > set errno to zero".

No, in C he is *not* wrong.

 > Feather is saying that the Holy Standard permits library functions to
 > generate errors ** without telling a soul **, because existing
 > compilers from vendors do this, and the Standard was engineered to
 > make existing compilers from powerful vendors correct!

You are making this up.  There are more ways to tell about errors than
setting errno.  Consider returning an error value as function result.

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

 

[Ben Bacarisse]

And you don't know encapsulation.

He doesn't say this and neither do I. The problem isn't that C binds
the programmer to 8 bit characters: the problem is that by default it
does.

That this (the 8 bit limit on char) is false has been pointed out by
others so I did not repeat the point and won't go round that argument
again.

My point is rather different. On a machine with 8-bit chars, how are
you "bound" to 8-bit characters if you can escape this bound simply by
using the right type (wchar_t) or the right encoding (multi-byte
characters using plain char)?

There is no default type in C. When you write a program you choose
the types. You don't get char "by default" you get it because that is
the type you choose. If it wrong (and C offers a better alternative)
that is hardly C's fault.

<snip>

 

[vippstar]

No, Feather is the pedant,

No to what? Jacob Navia, with the premises that Feather is
pedantically right and that this is not important concluded
(everything after claiming that Feather is pedantically right,
including premises and conclusion, is left implied obv.), that both
Schildt and Feather represent conflicting 'styles', therefore Schildts
'character assassination' is not justified any more than Feathers
character assassination would be.

This argument is valid, but one of the premises needs clarification on
what is important and what not, and which are the side-effects of
being important. Can you (or Navia) provide the definition?

since knowledge (cf Hellenistic philosophy,

Knowledge did not have a single definition in hellenistic philosophy,
in fact, it's one of the things schools of thought and philosophers
frequently 'battled' about. Can you be more specific or do you suggest
all the studying that must be done to learn every single definition of
knowledge of that age is actually *relevant* to our current
discussion?

Martha Nussbaum, Adorno, elsewhere) is that which contributes to human
survival and flourishing.

I'm sorry, but this definition has nothing to do with definitions I
have in mind from the hellenistic era (ie stoics). If you want to
direct someone to knowledge-related matters, the obvious thing to
mention is epistemology.

Sure, pure mathematical knowledge which does

What is 'pure mathematical knowledge'? Hilarious that you already use
a specialized term based on a more general one, having failed to
define the latter. PLEASE! More entertainment like this!

not seem at first glance to be about survival and flourishing is
knowledge: but it's "useless" knowledge which forms a part of a larger
whole that is independent of our minds.

Ah, I see. Very interesting.

And, "useless" knowledge in
pure mathematics (such as the complex number of the 19th century)
often turns out to have a physical (here, quantum theoretic) use after
all!

Hah! Who would imagine that! What interesting theories. I'm delighted.

But C, especially C99, is a man-made artifact running on enormous
automata which in the last analysis, sub specie aeternitatis, are
nothing more than finite automata (because their memory is finite if
large). Therefore if we may define "pedantry" as true knowledge that
does not in any significant way contribute to human survival and
flourishing, or form a part of that which so contributes (as does
math), then Feather is a pedant qed.

Absurd QED, like an end mark without the start.

 

[Ben Bacarisse]

You don't know the difference between two literary genres. One is
writing a computer book, the other is writing a standard.

The standard legislates what may be called C99. It is interpreted by
mere mortals by "language lawyers" in the same way as lawyers tell
clients the law.

It wouldn't surprise me, given the incompetence of the standard, if it
actually forbid library routines from zeroing errno. But I find it
hard to believe.

It does, and rightly so. It is more flexible that way.

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.

So, for anyone who wants to know... errno is never set to zero by any
library function. It is zero at program startup. The correct way to
use it is to set it to zero prior to one or more library function
calls and to test it afterwards. It is best to check it after just
one call, but the fact that it is never set to zero means that you can
test for errors in a whole expression with one inspection of errno.

But if errno is global wrt all library functions, the Standard casts
an extraordinarily poor design in concrete on behalf of compiler
vendors.

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

<snip>