🚀 go-pugleaf

In article <1993Jan26.013634.20451@nntpd.lkg.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
>In article <1993Jan25.213543.25499@pony.Ingres.COM> mikes@Ingres.COM (Mike Schilling) writes:
>>(a) Each scalar type has an unambiguous alignment requirement.
>For all existing C compilers?  Probably.  For all hypothetical standard
>conforming compilers?  Uncertain.  Actually it is imaginable, for a
>hypothetical but really meaningful compiler, if space is virtually free
>but speed is extremely expensive, one might want to align a 4-byte integer
>in the second half of an 8-byte cache line in order to save time by only
>filling half of a cache line.  I don't know if you'd call this unambiguous.

ISO 3.1 defines alignment as the requirement for objects of a given type
to have addresses that are multiples of some number. There are no
requirements for alignment that I can find, except that 6.5.2.1 requires
the alignment of structure members to be defined by the implementation.

>>(b) Each scalar type's alignment requirement is a power of two.

There is no such requirement in the standard.

>>(c) The offset of the first member of a structure is 0.
>Probably.  A structure pointer cast to the type of the structure's first
>member, or vice-versa, must still point to the right place.  And there cannot
>be a "hole" at the beginning of a structure.  I'm not sure if this proves
>that "offsetof" that member must yield a 0 result.

"offsetof" is defined as giving the offset of a member; this term is not
further defined. Common-sense (which doesn't always work with the C
standard) would say that your statement is true.

>>(d) The offset of the (n+1)th member of a structure is the offset of
>>    the nth member of the structure, plus the size of the nth member,
>>    rounded up to the alignment requirement of the type of the (n+1)th member.
>I think the answer to (a) fits here.

It is arguable from the wording of 6.5.2.1 that only the minimal padding
may be provided (in other words, item (d) is true), but Norman's answer
to (a) makes it effectively useless (i.e. there is no way to determine
the alignment requirement of the type of the (n+1)th member without
reading the vendor's manual (which must state it)).

>>(e) The alignment required by the structure is equal to the most restrictive
>>    alignment of any of its members.
>No.  It seems to be mostly agreed (though I'm not sure if I agree) that the
>standard permits, and in some cases compilers do, align structures more
>strictly than the most restrictive alignment of any of its members.

Again, 3.1 allows this provided that the vendor documents it.

>>(f) The size of the structure is the offset of the last member of the structure,
>>    plus the size of the last member, rounded up to alignment required
>>    by the structure.
>I think the answer to (a) fits again here.

Ditto. The answer to (e) makes this impossible to determine programatically.

>>Question 3:  On at least one platform, pointers to characters were represented
>>diferently from pointers to anything else
>>On such platforms, how are pointers to structures represented?
>I think it's unspecified.  The implementation has to do something that will
>work, but I don't think they have to tell you what they've done.

Indeed. Note that on such an implementation, a structure containing one
"char" field may need a alignment of (say) 8, precisely so that
"pointers to anything else" can point to them. This justifies the answer
to (e).

-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | Vision Park         | it will get its revenge.
Phone: +44 223 236 555 | Cambridge   CB4 4RZ |   - Henry Spencer
Fax:   +44 223 236 550 | United Kingdom      |