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