address of structure == address of first member?

Doug Gwyn gwyn at smoke.BRL.MIL
Sun Nov 27 22:03:50 AEST 1988


In article <14725 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>To be completely type-correct, we should convert `p' into a pointer to
>the correct structure type-name, and follow that to its `name' field.
>The problem, of course, is that in this general-purpose search routine,
>we have no idea *which* structure `p' is standing for [to end the
>sentence a preposition with].  There are two alternatives: define a
>structure that contains only a name; or cheat.

Technically it is not necessary to do this via a purely "type correct"
method; there are sufficient requirements imposed by the very latest
proposed C standard to ensure that any addressable data object forms a
linear address subspace within itself, such that (char *)-arithmetic
suffices to correctly address its pieces.  This guarantee was necessary
to make memcpy() etc. usable for their intended purposes.

Cheating is guaranteed to suffice.  A pointer to a structure converted
to (char *) must compare equal to a pointer to the first member of the
structure converted to (char *), and in this particular example casting
that back to (char **) will produce a valid pointer to the first
structure whose type is (char *).  Then * will pick up the contents of
that (char *) for use with strcmp().  (I made a mistake about this in
my previous posting. strcmp() does need the (char *) itself, not just
its address, so the additional *(char**) is necessary.  Sorry.)

I admit to being surprised fairly recently when I found that this
"cheating" was supposed to be officially sanctioned, but it's useful.

The wording about "same representation and alignment" was also fixed
so that one can safely pass a nonnegative int to a function expecting
an unsigned int, or a non-qualified type to a function with parameter
declared as a qualified version of that type, etc.  This (along with
a fix to the definition for fprintf() %u format) seems to complete
the work of making C object representations behave as usefully as
possible without undue burden for implementors on segmented, ones-
complement, etc. architectures.

A further nice thing is that the K&R 2nd Ed. example where a pointer
to a function of a slightly different type than expected was passed
(for a sorting comparison function, I think) is now guaranteed to
actually work the way K&R used it.  This had been bothering me..



More information about the Comp.lang.c mailing list