structure element offsets

[David Messer]

In article <7377 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
 >> According to K&R all
 >> that is required is that (type *)(long *)x == x.
 >
 >False.  Please cite chapter and verse.  I believe what you are thinking
 >of is (type *)(char *)x == x, which is (by K&R) valid.  Your example falls
 >down if, for example, "type" is "char" and the format of "long *" is not
 >precise enough to point to an individual char within a long.
 >
 >Or perhaps you were thinking of (type *)(long)x == x ?  That would make me
 >nervous but it is technically valid.

You are correct.  The second example is what I meant.  (I.e. a pointer
can be stored in a long variable and converted back with out changing
it's value.)  For those of you interested, the section of K&R that
I am looking at is 14.4 of Appendix A (C Reference Manual).  It is
interesting in that the only thing gaurenteed about casts on pointers
is the conversion to a long and back (actually, conversion to an
"integral" type (int or long) and back, where the choice of int or
long is machine-dependent.) and conversion to a pointer to a smaller
type and back, which also results in the same original pointer value.
The mapping from a pointer to a long (int) is explicitly machine
dependent, although it is supposed to be "unsurprising to those who
know the addressing structure of the machine."  One interesting
thing is, by these rules, the use of malloc(), for anything other
than char arrays, is non-portable.

 >
 >> ... for good or ill,
 >> C has been defined such that all members-of-structures share the
 >> same name-space...
 >
 >Not modern C, which puts each structure's members in a separate name space.

If so, most existing programs which use structures will not compile.
I haven't seen any compilers that insist on members-of-structures
being tied to a specific structure, although I know that the
"standardization" effort has it that way.  (What ever happened to
the days when a standards committee codified existing practises
rather than doing a re-engineering job?)
-- 
Disclaimer:                       | David Messer 
I'm always right and I never lie. | Software Consultant 
My company knows this and agrees  | UUCP:  ihnp4!quest!viper!dave 
with everything I say.            |        ihnp4!meccts!viper!dave