[comp.lang.c] pointers

msb@sq.uucp (Mark Brader) (09/27/88)

> > > 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@sq.com				-- Pontus Hedman

henry@utzoo.uucp (Henry Spencer) (10/01/88)

In article <1988Sep26.182431.7946@sq.uucp> msb@sq.com (Mark Brader) writes:
>Harrumph.  The cast not only can, but *does* involve a conversion.

Picky, picky, picky...

>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.

Inter-module compatibility's main effect is that it puts limits on how
tricky the compiler can be within a single module, because certain aspects
of the trickery have to be consistent across modules.

>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?

The original discussion was about aggregate objects ("aggregate" is used
loosely, possibly not in the precise sense X3J11 uses) in which the
internal structure is programmer-visible.  An int is not a relevant example.

However...  I'm coming to think that Mark is right (although it does come
under the heading of "something no sensible implementor would do").  I was
misled by a related problem that I'd studied at some length.  So long as
the compiler knows about all the conversions being done, which it should
for a portable program, it can fool around as it pleases internally.  So
the implications for out-of-range pointers result from common practice
rather than logical necessity.
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu