> > Just to make sure:
> > The question itself specifies that the machine is little endian and
> > has a 32-bit word alignment for memory access and an unsigned integer
> > is 32 bit long. Does that make the answers explicit/valid, or are the
> > answers still implementation specific?
>
> Well, your answers demonstrate one reasonable response to the code by an
> implementation on such a platform. Possibly the *most* reasonable
> response. Unfortunately for the purpose of your question, the C Standard
> does not require that implementations must be reasonable; it requires only
> that they act in accordance with the Standard. And it is certainly
> possible - even easy - to imagine answers different to yours that are
> still in accordance with the Standard, even on such hardware as you
> specify.

Thanks again for your answers!

Could you give some "easy" examples of how the answers could be
different while still running on the specified hardware?

BRs!

On Thu, 18 Oct 2007 04:26:19 -0700, in comp.lang.c , dspfun
<dspfun@hotmail.com> wrote:

>> > Just to make sure:
>> > The question itself specifies that the machine is little endian and
>> > has a 32-bit word alignment for memory access and an unsigned integer
>> > is 32 bit long. Does that make the answers explicit/valid, or are the
>> > answers still implementation specific?
>>
>> Well, your answers demonstrate one reasonable response to the code by an
>> implementation on such a platform. Possibly the *most* reasonable
>> response. Unfortunately for the purpose of your question, the C Standard
>> does not require that implementations must be reasonable; it requires only
>> that they act in accordance with the Standard. And it is certainly
>> possible - even easy - to imagine answers different to yours that are
>> still in accordance with the Standard, even on such hardware as you
>> specify.
>
>Thanks again for your answers!
>
>Could you give some "easy" examples of how the answers could be
>different while still running on the specified hardware?

Many compilers offer a pragma "pack" which alters how memory is laid
out in unions and structs.
A 16-bit compiler might give a different answer from a 32-bit compiler
on the same hardware (ISTR that MSVC 1.5 and MSVC 4.0 managed this).

Further discussion is probably offtopic here.




--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

On Oct 18, 12:26 pm, dspfun <dsp...@hotmail.com> wrote:
> > > Just to make sure:
> > > The question itself specifies that the machine is little endian and
> > > has a 32-bit word alignment for memory access and an unsigned integer
> > > is 32 bit long. Does that make the answers explicit/valid, or are the
> > > answers still implementation specific?
>
> > Well, your answers demonstrate one reasonable response to the code by an
> > implementation on such a platform. Possibly the *most* reasonable
> > response. Unfortunately for the purpose of your question, the C Standard
> > does not require that implementations must be reasonable; it requires only
> > that they act in accordance with the Standard. And it is certainly
> > possible - even easy - to imagine answers different to yours that are
> > still in accordance with the Standard, even on such hardware as you
> > specify.
>
> Thanks again for your answers!
>
> Could you give some "easy" examples of how the answers could be
> different while still running on the specified hardware?

The compiler might put 37 bytes of padding between the two members of
struct A. That would be an odd thing for it to do, but it would be
perfectly valid and fully compliant with the C Standard.

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

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?

BRs!

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

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 !

James Kuyper Jr. wrote:

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

ITYM 24 possible orderings. Just like there are 32! possibilities with
32 bits, there are 4! possibilities with 4 bytes. 4! = 24.

Peter Pichler wrote:
> James Kuyper Jr. wrote:
>
> > 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.
>
> ITYM 24 possible orderings. Just like there are 32! possibilities with
> 32 bits, there are 4! possibilities with 4 bytes. 4! = 24.

You're right. Also, I'm not too sure about the number that are in
actual use; I've seen what claimed to be a definitive list, and I
think the number of entries in that list was 8, but I'm not sure where
to find that list, and I'm not willing to swear on the accuracy of my
memory. The important point, of course, is that it's a lot larger than
2.