Even more errors in Schildt's books.

[Seebs]

Here's what got me. I had the book still open to page 464 (from looking
something up), and happened to glance over at 465.

strtoll
#include <stdlib.h>
long long int strtoll(const char * restrict start,
char ** restrict end, int radix);

strtoll() was added by C99.

The strtoll() function is similar to strtol() except that it
returns a long long int. If the result cannot be represented
by a long integer, LLONG_MAX or LLONG_MIN is returned, and the
global errno is set to ERANGE, indicating a range error. If
start does not point to a number, no conversion takes place and
zero is returned.

(Side note: strtol() doesn't have restrict in C:TCR, but the text explains
that it does in C99, so that's fine.)

Consider, if you will, a machine on which LLONG_MAX > LONG_MAX, and a
call to strtoll() with a string containing a value equal to LONG_MAX + 1.
According to Schildt, it will return LLONG_MAX.

Now, this is pretty trivial to figure out -- clearly, a cut and paste
followed by not editing. Still, I think this suggests that maybe it's time
to come up with some kind of taxonomy for these errors, so we can sort
them by type, severity, or humor value.

-s

 

[spinoza1111]

Here's what got me.  I had the book still open to page 464 (from looking
something up), and happened to glance over at 465.

        strtoll
                #include <stdlib.h>
                long long int strtoll(const char * restrict start,
                        char ** restrict end, int radix);

        strtoll() was added by C99.

        The strtoll() function is similar to strtol() except that it
        returns a long long int.  If the result cannot be represented
        by a long integer, LLONG_MAX or LLONG_MIN is returned, and the
        global errno is set to ERANGE, indicating a range error.  If
        start does not point to a number, no conversion takes place and
        zero is returned.

(Side note:  strtol() doesn't have restrict in C:TCR, but the text explains
that it does in C99, so that's fine.)

Consider, if you will, a machine on which LLONG_MAX > LONG_MAX, and a
call to strtoll() with a string containing a value equal to LONG_MAX + 1.
According to Schildt, it will return LLONG_MAX.  

Now, this is pretty trivial to figure out -- clearly, a cut and paste
followed by not editing.  Still, I think this suggests that maybe it's time
to come up with some kind of taxonomy for these errors, so we can sort
them by type, severity, or humor value.

You fail to notice that Schildt is using "long integer" in its
contemporaneous sense because unlike you, he's a professional
programmer and knows several languages...whereas it appears to us that
you do not in actuality know C in the sense of being able to come up
with any competent code.

At this time, "long integer" where "integer" is spelled out doesn't
mean the same thing as "long int" in C. "long int" in C means a 32 bit
integer. Whereas "long" on contemporary platforms means a 64 bit
integer...what C calls a long long integer.

You have told us you're autistic with ADHD and "not
neurotypical" (http://www.seebs.net/log/articles/460/thoughts-on-
neurotypicality-), and you've asked, implicitly, for our charity for
having such a fashionable disease, which we'd be delighted to extend
except for the fact that you do not show that charity at all towards
others.

But: if you learn and perform is a way that is so very Special, your
theories of learning and education are useless to us. Schildt is
addressing, in some measure, people who come to C from languages where
a long integer, where integer is spelled out, is today 64 bits. "long
long" is idiomatic to C and used nowhere else.

 

[DDD]

In a nut shell, long integer is not "long int"?

You fail to notice that Schildt is using "long integer" in its
contemporaneous sense because unlike you, he's a professional
programmer and knows several languages...whereas it appears to us that
you do not in actuality know C in the sense of being able to come up
with any competent code.

At this time, "long integer" where "integer" is spelled out doesn't
mean the same thing as "long int" in C. "long int" in C means a 32 bit
integer. Whereas "long" on contemporary platforms means a 64 bit
integer...what C calls a long long integer.

You have told us you're autistic with ADHD and "not
neurotypical" (http://www.seebs.net/log/articles/460/thoughts-on-
neurotypicality-), and you've asked, implicitly, for our charity for
having such a fashionable disease, which we'd be delighted to extend
except for the fact that you do not show that charity at all towards
others.

But: if you learn and perform is a way that is so very Special, your
theories of learning and education are useless to us. Schildt is
addressing, in some measure, people who come to C from languages where
a long integer, where integer is spelled out, is today 64 bits. "long
long" is idiomatic to C and used nowhere else.

 

[SG]

You fail to notice that Schildt is using "long integer" in its
contemporaneous sense because unlike you, he's a professional
programmer and knows several languages...whereas it appears to
us

Speak for yourself. It appears to me that Schildt could and should
have been much more precise (once again). All to often you include
everybody else in an "us" or "we" but most readers probably wouldn't
agree with you. No, I also can't speak for everybody else. It's just
my estimation of the situation.

[...] "long int" in C means a 32 bit integer.

Since when? You do know that a "long int" in the LP64 model (like GCC
uses for 64bit Linux) is actually a 64 bit integer, right?

Whereas "long" on contemporary platforms means a 64 bit
integer...what C calls a long long integer.

Saying "long integer" to mean "long long int" it not at all obvious.
But it /is/ obvious that it /can/ be misinterpreted which is why
Schildt should have been more precise. Also, of course, C only
specifies minimum sizes (char at least 8 bits, short at least 16, int
at least 16, long at least 32, long long at least 64) -- at least in
the case of ISO/ANSI C. I don't know what kind of C you and Schildt
have in mind.

 

[Ian Collins]

You fail to notice that Schildt is using "long integer" in its
contemporaneous sense

<insulting twaddle snipped>

Nonsense.

At this time, "long integer" where "integer" is spelled out doesn't
mean the same thing as "long int" in C. "long int" in C means a 32 bit
integer. Whereas "long" on contemporary platforms means a 64 bit
integer...what C calls a long long integer.

Complete bollocks. It has no such meaning on any platform I use.

Any professional programmer with a double digit IQ can learn how to snip
Usenet posts.

 

[Keith Thompson]

In a nut shell, long integer is not "long int"?

[...]

Maybe.

C uses the term "integer" to refer to a set of types, including
char, short, int, long, long long, unsigned varieties of each
(plus signed char), and possibly more. The type "int" is just one
of the integer types.

The word "int" is clearly an abbreviation of "integer", but the terms
"int" and "integer" mean quite different things.

C doesn't use the term "long integer". A writer who uses that phrase
in a C context *probably* means "long int", though it's conceivable
that he means something else. In any case it's nearly certain that
he should have used a less ambiguous phrase.

As for what Schildt meant by "long integer" in this particular
context, his description of strtoll(), a look at his description
of strtol() would probably be instructive. I don't have the book,
but my guess is that he also used the term "long integer" in the
description of strtol(), and that it obviously referred to the type
"long int".

 

[Seebs]

As for what Schildt meant by "long integer" in this particular
context, his description of strtoll(), a look at his description
of strtol() would probably be instructive. I don't have the book,
but my guess is that he also used the term "long integer" in the
description of strtol(), and that it obviously referred to the type
"long int".

It's surprisingly inconsistent.

The corresponding language:

strtod: If overflow occurs...
strtof: If overflow occurs...
strtol: If the result cannot be represented by a *long int*...
strtold: If over flow occurs...
strtoll: If the result cannot be represented by a long integer...
strtoul: If the result cannot be represented as an unsigned long integer...
strtoull: If the result cannot be represented as an unsigned long integer...

"*long int*" represents something bolded.

Conclusion: We do not have enough information to be totally sure of
what this meant. I don't know why the unsigned ones get "as"
instead of "by". It's clearly erratic editing.

However, this is unwinnable for Schildt. If "long integer" means any
of the integer types which are longer than int, then strtoul's description
is incorrect. If it means long specifically, as opposed to long long,
then the descriptions of strtoll and strtoull are wrong.

-s