On 19 Okt, 13:33, "James Kuyper Jr." <jameskuy...@verizon.net> wrote:
> dspfun wrote:
> > Thank you for your answers!
>
> > To try to conclude by refering to the sections of the C-standard I
> > beleive question a) above is implementation defined due to the
> > following text in the C-standard:
> > ---------------------------------------------
> > 6.5.3.4 The sizeof operator
> > 4. The value of the result is implementation-defined, and its type (an
> > unsigned integer type) is size_t, defined in <stddef.h> (and other
> > headers).
> > ---------------------------------------------
>
> More importantly:
> 6.7.1p13: "... There may be unnamed padding within a structure object, ...."
>
>
>
>
>
> > Question b) is implementation defined due to the following text in the
> > C-standard:
> > ----------------------------------------------
> > 6.2.6.1 General
> > 6 When a value is stored in an object of structure or union type,
> > including in a member object, the bytes of the object representation
> > that correspond to any padding bytes take unspecified values.42) The
> > value of a structure or union object is never a trap representation,
> > even though the value of a member of the structure or union object may
> > be
> > a trap representation.
>
> > 7 When a value is stored in a member of an object of union type, the
> > bytes of the object representation that do not correspond to that
> > member but do correspond to other members take unspecified values.
>
> > 6.7.2.1 Structure and union specifiers
> > 15. There may be unnamed padding at the end of a structure or union.
> > ----------------------------------------------
>
> > Do you agree?
>
> Well, you've left out the most important one:
> 6.2.6.1p1: "The representations of all types are unspecified except as
> stated in this subclause."
>
> While the standard specifies many features of the representation of
> integer types, it always refers to bits in terms of their value, not in
> terms of their physical locations withing the integer object. In
> principle, a conforming implementation could store the bits that make up
> a 32-bit integer in any order it wants, just so long as it implements
> the bit-wise operators to handle those bits in that same order. The
> standard doesn't ordain any particular connections between the ordering
> used in an integer type and the ordering used in unsigned char.
>
> There are 32! possible orderings of 32 bits, though only a small number
> of those orderings are actually used. However, I've read that of the 12
> possible orderings of the 4 bytes underlying a 4-byte integer, 8 of them
> are in actual use. The simplistic dichotomy between little- and
> big-endian architectures doesn't cover all of the possibilities (though
> it does cover most of the popular ones).- Dölj citerad text -
>
> - Visa citerad text -

Thank you for your !