Re: K&R2 Secition 5.9 - major blunders

From: TTroy (tinesan_at_gmail.com)
Date: 03/07/05


Date: 6 Mar 2005 23:01:26 -0800

Martin Ambuhl wrote:
> TTroy wrote:
> > I FOUND MAJOR ERRORS in K&R2 (making it almost useless for the
herein
> > mentioned topics).
> >
> > K&R2 Section 5.9 Pointers vs. Multidimension Arrays starts of like
> > this...
> >
> > "Newcomers to C are somtimes confused about the difference between
a
> > two-dimensional array and an array of pointers..."
> >
> > then continues to explain int *b[10]; to be...
> >
> > "For b, however, the definition only allocates 10 pointers ...
Assuming
> > that each element of b does point to a twenty element array,then
there
> > will be 200 ints set aside, plus ten cells for pointers... "
> >
> > Is it just me, or is that explanation only valid for int (*b)[10];
> > ????
>
> It's just you; and you are dead wrong.
> int *b[10];
>

Each element of b doesn't point to a 20 element array of int. Each
element of b points to an int. The authors should have said "Assuming
that each element of b does point to an int which happens to be the
first element of a 20 int array." This mistake is crucial because
there really exists something totally different that fits their "not
very accurate" description. This leads to confusion. If I point at a
pencil and tell you that it's an instrument to write with and it has
ink in it which is permanent, then that's a big mistake for two
reasons: I'm 'slightly' off on my explanation of the pencil, and most
importantly, my explanation is really the qualities of something else:
a pen.

>
> is the declaration for an array[10] of pointers to int.
> int (*b)[10];
> is the declaration for *one* pointer to an array[10] of int.
>

Yeah, I meant int (*b[10])[20]; This exactly fits the description.

> >
> > I'm pretty sure K&R2 is totally wrong in this section (had me
confused
> > for a while).
>
> You dead wrong.
>

I gave an explanation as to why I thought K&R2 was wrong, but you gave
no explanation to explain why I am 'dead wrong.' All you did was
explain what thoise two definitions above were, without relating it to
anything.

>
> This is frequently the case for people who are "pretty
> sure" that a text that has been gone over carefully for some 30 years
is
> wrong.
>

I'm pretty sure it's wrong (the explanation is "close" to the truth,
but since it's accurately describing something totally different,
that's what makes it very wrong).

>
> >
> > Later on in section 5.9, it says "... by far the most frequent use
of
> > arrays of pointers is to store character strings of diverse
lengths..."
> >
> > Once again, this seems totally wrong.
> > char *strings[] = {"Bob","Dave","Jack");
> > 'strings' is only managing pointers to anonymous objects that are
> > automatically created by the initialization (which there is no
mention
> > of in this section). 'strings' doesn't strore "Bob" "Dave" "Jack".
>
> The use of the array of pointers is to store the strings.
>

No it's not, and thinking like this is dangerous. Say you have a
structure that you want to have strings in it, if you chose to have a
(char *) array in it, and you *think* it's holding the strings, you'll
be in big trouble if you try to write the structure to a file. Arrays
of pointers to char that point to anonymous string objects are just
'managing' references to the strings (by pointing to their first
characters).

>
> 'strings'
> doesn't do anything, so that it doesn't store is beside the point as
> much as that it doesn't do integrals. It's an array.

Besides the point? If it isn't for the diagram that following their
explanation, this would been a very dangerous mistake. Also there is
no mention of how the strings are created or where they are actually
stored, which compounds the mistake. And also again, the
initialization with definition makes it look like the strings are
actually being stored in the array too.

ex:

"... by far the most frequent use of
arrays of pointers is to store character strings of diverse lengths..."

followed by:

char *strings[]= {"string1", "string2", "string3");

This might confuse very many newbie readers (it didn't confuse me, but
the mistake I mentioned above did). It *looks* like the strings are
being stored in the array, and the literature above it implies storage.
 Plus the [] array notion also implies storage. Also the lack of
explanation of how/where these strings are stored also implies they are
stored in the strings array.

All I'm requesting is all the people who maintain errata lists for this
book take this into account.



Relevant Pages

  • Re: K&R2 Secition 5.9 - major blunders
    ... Each element of b doesn't point to a 20 element array of int. ... This mistake is crucial because ... my explanation is really the qualities of something else: ... > The use of the array of pointers is to store the strings. ...
    (comp.lang.c)
  • Re: Returning array of strings through callback from unmanaged to
    ... Is the array of strings a jagged array or fixed length array? ... It is imperative that I am able to return the array of strings from the ... I have control over how many strings I want the unmanaged code to return ... What I want to accomplish is to pass a callback function to unmanaged ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: attempting to return values from array from w/in a function
    ... What I get is an array w/ only the most recent array entry. ... I am new to PHP & do not have formal scripting ... you end up comparing strings, but the test you mean probably is simply: ... case 1: {codeblock} ...
    (comp.lang.php)
  • Re: K&R2 Secition 5.9 - major blunders
    ... Would changing 'point to a' to 'point into a' twenty element array be ... > arrays of pointers is to store character strings of diverse ... comparison between what was really happening (arrays of pointers to ... pointer to a string(this probably would confuse beginners)" and ...
    (comp.lang.c)
  • Re: Concatenate integer to string
    ... F2003 adds allocatable-length strings. ... Since a character with allocatable ... It seems that the deferred length has a special proparty, different from a deferred array size, in that the standard assignment operator will allocate the length. ...
    (comp.lang.fortran)