Perplexed by pointers

Doug Gwyn gwyn at smoke.BRL.MIL
Sun Nov 27 22:57:39 AEST 1988


In article <1537 at mit-caf.MIT.EDU> vlcek at mit-caf.UUCP (Jim Vlcek) writes:
-People here paid too much attention to the pointer types, and not
-enough attention to the values!  The original cast to (char *) is only
-done to be able to correctly perform the necessary pointer arithmetic,
-for in fact ``table'' is in no sense really a pointer to char.  I'm
-suprised that the notion of *(char **) amounting to a no-op managed to
-breeze by Doug Gwyn!

Yes, I apologize.  I was concentrating on the types issue and didn't
pay attention to the fact that the struct contained a pointer to the
string to be compared not the string (char array) itself.  Sorry.
The *(char**) is indeed necessary to pick up the pointer to the string.

If you check out the wording in the articles to which I was responding,
it should be easy to see how I was misled:

>*-  Huh?  The type of the expression ((char *)table + (m * size)) is
>*-  "pointer to char", no?  And the usage on line 86 requires "pointer to
>*-  pointer to char".  If I dereference the subexpression above, e.g.
>*-  *((char *)table + (m * size)), the result type is "char", not "pointer
>*-  to char" as required by strcmp().  Or am I just being dense?

The referenced discussion is all about types and not about semantics.
It is true, as I said, that starting from a (char *) one doesn't need
to apply *(char**) to it to produce a (char *), but one DOES need to
do that to access the pointer member of the array in order to find the
string in question.  If the operation had been on the struct member
itself then the original (char *) would already have been suitable
for accessing it via a function taking (char *) pointers.



More information about the Comp.lang.c mailing list