pointers
Mark Brader
msb at sq.uucp
Tue Sep 27 08:24:31 AEST 1988
> > > The situation unfortunately isn't as symmetrical as it looks, because
> > > a pointer to an array element points to the *beginning* of the array
> > > element.
> >a pointer to an array element *is typically implemented as* pointing to
> >the beginning of the array element...
> Remember, for example, that a pointer to a struct, suitably cast, is
> *required* to point to its first member. Okay, you can say that the cast
> can involve a conversion... but when you pay careful attention to the
> rules about pointers to unions, such schemes start coming unravelled.
> When you look very carefully at the combination of the rules for pointers
> to structs, pointers to unions, pointers to arrays whose members are also
> arrays, compatibility across separately-compiled modules, etc., it's very
> hard to do seriously unorthodox things with pointers without breaking a
> rule somewhere.
Harrumph. The cast not only can, but *does* involve a conversion.
The question is whether the conversion changes any bits. Most of the
examples you talk about also involve conversions, and the same thing
applies. Inter-module compatibility doesn't, but there are very few
requirements here.
Now, as a counterexample to the original assertion, consider a word-
addressed machine where an "int" occupies one word. Do you seriously
want to say that an "int *" points to a particular byte of the word?
A pointer can be implemented as pointing to the object addressed in almost
any fashion, as long as it is *deducible* exactly which bytes constitute
the object.
Mark Brader "True excitement lies in doing 'sdb /unix /dev/kmem'"
utzoo!sq!msb, msb at sq.com -- Pontus Hedman
More information about the Comp.lang.c
mailing list