little endian or big endian ???

[Richard Tobin]

No. To determine endianness, you have to dereference the same address
as each of two different types, so a cast is quite natural. You could
do it with a union instead.

Was that something that changed in C99? C89 says,

3.3.2.3 Structure and Union Members
[...]

With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined.[/QUOTE]

Yes, it's implementation-defined. Typically the implementation will
define reading an int as an array of char to read the bytes of the int
in some order, known as the byte order

*Any* test of endianness is bound to use implementation-defined or
undefined behaviour, otherwise all machines would be found to have the
same endianness!

-- Richard

 

[Walter Roberson]

No. To determine endianness, you have to dereference the same address
as each of two different types, so a cast is quite natural. You could
do it with a union instead.

Was that something that changed in C99? C89 says,

3.3.2.3 Structure and Union Members
[...]

With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined. One special guarantee is made
in order to simplify the use of unions. If a union contains several
structures that share a common initial sequence (see below), and if
the union object currently contains one of these structures, it is
permitted to inspect the common initial part of any of them.

 

[CBFalconer]

.... snip ...

Can you tell me how it is flawed? Is it because of casting from
int* to char* ?

For example, with a 32 bit int, you have 32 places for the most
sig. bit, 31 for the next bit, etc. for 32! total possibilities.
Yes, some combinations are more likely, but that isn't detecting,
it is discriminating.

 

[Walter Roberson]

*Any* test of endianness is bound to use implementation-defined or
undefined behaviour, otherwise all machines would be found to have the
same endianness!

Take an unsigned integral type. C promises no internal padding
and no trap representations. Initialize it. Take its address and cast the
address to unsigned char pointer. C defines this transformation
as being possible and that the resulting unsigned chars will
each have no internal non-value bits and no trap representations.
Now read through the unsigned char array. If the sizeof the
unsigned integral type exceeds the number of bits you initialized
to, then the value bits may be spread out in unusual ways,
most likely by all-0 unsigned char showing up, but perhaps more
complicated patterns are possible? (I'd have to go back and
re-check the values implementation clause.) But you could track
each bit by shifting it through the unsigned integral type and
seeing where it shows up in the unsigned char array.

Tracking down non-value bits and sign representation for signed
integral types -- that's harder.

 

[Richard Tobin]

*Any* test of endianness is bound to use implementation-defined or
undefined behaviour, otherwise all machines would be found to have the
same endianness!

[/QUOTE]

Take an unsigned integral type. C promises no internal padding
and no trap representations. Initialize it. Take its address and cast the
address to unsigned char pointer. C defines this transformation
as being possible and that the resulting unsigned chars will
each have no internal non-value bits and no trap representations.
Now read through the unsigned char array.

.... and the values you get will be implementation-defined. I suppose
it's less implementation-defined in that it's bound not to crash,
which is presumably allowed in the union case.

But the first sentence you quoted from C90 *has* been removed in C99.
It still talks about the exceptional case, but without mentioning the
non-exceptional one. Perhaps the text has been moved elsewhere.

And I note that in C90 that very sentence has a footnote mentioning
the use of unions for determining byte order.

-- Richard

 

[Clever Monkey]

You're /surely/ not serious.


You're /surely/ not serious.

He is. And stop calling him Shirley.

 

[CBFalconer]

.... snip ...

Take an unsigned integral type. C promises no internal padding
and no trap representations. Initialize it. Take its address and
cast the address to unsigned char pointer. C defines this
transformation as being possible and that the resulting unsigned
chars will each have no internal non-value bits and no trap
representations. ....

Nonsense.

 

[Walter Roberson]

Walter Roberson wrote:

Nonsense.

Hmm? Which part is nonsense? Is it the part of C89 3.3 Expressions
that says, "An object shall have its stored value accessed only
by an lvalue that has one of the following types:
[...] - a character type" ?

 

[CBFalconer]

Walter Roberson wrote:

Nonsense.

Hmm? Which part is nonsense? Is it the part of C89 3.3 Expressions
that says, "An object shall have its stored value accessed only
by an lvalue that has one of the following types:
[...] - a character type" ?

I think the following quote (from N869) is adequate:

6.2.6.2 Integer types

[#1] For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided into
two groups: value bits and padding bits (there need not be
any of the latter). If there are N value bits, each bit
shall represent a different power of 2 between 1 and 2N-1,
so that objects of that type shall be capable of
representing values from 0 to 2N-1 using a pure binary
representation; this shall be known as the value
representation. The values of any padding bits are
unspecified.39)

 

[Richard Bos]

This most probably isn't a homework question. Its a typical question
thats asked mostly in interviews in India.

It's also a typical question that's asked in many badly thought out
computing courses.

Can you tell me how it is flawed?

I can, but I won't. The whole exercise is a wild goose chase, and I'm
not going to help you by telling you which other wild species of goose
you could chase. That would only make a futile pursuit differently
futile, not less.

Richard

 

[John Bode]

This most probably isn't a homework question. Its a typical question
thats asked mostly in interviews in India.

Which makes it all the more depressing, both that an interviewer would
bother to ask it and that the candidate would need help finding the
answer. If you don't at least have a rough idea of how to figure this
out by the time you're looking for a job, you shouldn't be looking for
a job yet.

As worded, though, this sounds like a typical intro programming
assignment.

Can you tell me how it is flawed? Is it because of casting from int*
to char*

It would miss weird things like VAX floats, which were "middle-
endian" (byte order 2301).