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

jameskuyper@verizon.net writes:
> 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.

Interesting. I think the only ones I've ever heard in actual use are
big-endian, little-endian, and PDP-11-endian (the latter joins two
little-endian 16-bit words into a big-endian 32-bit longword). Does
anyone know of other examples in real life?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

What in the standard prohibits the use of different bit-orderings to
represent integers, such that, say, the most significant bit and the
least significant bit are in the *same* byte (and next to each other)?

(Not that I expect anyone to actually take advantage of this if it is allowed).

On Oct 19, 7:36 pm, gordonb.e8...@burditt.org (Gordon Burditt) 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.
>
> What in the standard prohibits the use of different bit-orderings to
> represent integers, such that, say, the most significant bit and the
> least significant bit are in the *same* byte (and next to each other)?

I'm not able to look up whether there is such a clause or not, but it
doesn't really matter. Bitwise operations are defined in terms of
arithmetic, and you shouldn't need to know the representation for
portable code anyhow.

On Oct 19, 8:16 pm, Justin Spahr-Summers
<Justin.SpahrSumm...@gmail.com> wrote:
> On Oct 19, 7:36 pm, gordonb.e8...@burditt.org (Gordon Burditt) 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.
>
> > What in the standard prohibits the use of different bit-orderings to
> > represent integers, such that, say, the most significant bit and the
> > least significant bit are in the *same* byte (and next to each other)?
>
> I'm not able to look up whether there is such a clause or not, but it
> doesn't really matter. Bitwise operations are defined in terms of
> arithmetic, and you shouldn't need to know the representation for
> portable code anyhow.

I spoke much too soon. I found a draft of the standard real quick and
realized my mistake. Only bitwise shift operations are defined in
terms of arithmetic, apparently. I don't know how much that changes,
however.

Gordon Burditt wrote:

> What in the standard prohibits the use of different bit-orderings to
> represent integers, such that, say, the most significant bit and the
> least significant bit are in the *same* byte (and next to each other)?

Nothing does.

"next to each other" doesn't mean anything.
Bits in the same byte are only distiguishable
by the values that they represent.

--
pete

Gordon Burditt 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.
>
> What in the standard prohibits the use of different bit-orderings to
> represent integers, such that, say, the most significant bit and the
> least significant bit are in the *same* byte (and next to each other)?

Nothing - that is how Gordon and I both calculated that there are 32!
possible bit orderings for a 32-bit integer.

pete wrote:
> Gordon Burditt wrote:
>
>> What in the standard prohibits the use of different bit-orderings to
>> represent integers, such that, say, the most significant bit and the
>> least significant bit are in the *same* byte (and next to each other)?
>
> Nothing does.
>
> "next to each other" doesn't mean anything.
> Bits in the same byte are only distiguishable
> by the values that they represent.

Yes, but those bits can represent values in at least two different
types: the 32 bit type, or unsigned char. It's both meaningful, and
important, to realize that the standard imposes no requirements
connecting the value represented by a given bit in those two different
types.

Exception: if unsigned char is a 32 bit type, and the 32 bit integer
type we're comparing it with is char, signed char, or unsigned char,
then there is a required connection, of course.