Re: byte order

On Tue, 08 Jan 2008 22:48:16 +0100, Pascal Bourguignon
<pjb@xxxxxxxxxxxxxxxxx> wrote:

"Jeff M." <massung@xxxxxxxxx> writes:

On Jan 8, 2:37 pm, Raymond Wiker <r...@xxxxxxxxxxxx> wrote:
"Jeff M." <mass...@xxxxxxxxx> writes:
On Jan 7, 2:02 pm, Pascal Bourguignon <p...@xxxxxxxxxxxxxxxxx> wrote:
Rainer Joswig <jos...@xxxxxxx> writes:
is there a way to determine the byte order
of the underlying 'machine'? Portable?

Not in Common Lisp.

Not in standard C either.

You're joking, right?

// returns 1 if little endian, 0 if big
int am_i_little_endian() {
int x = 0x12345678;
char* b = (char*)&x;
return *b == (x & 0xFF);
}

Are you *absolutely* sure that's standard C, and not just
something that happens to work most of the time?

Tell ya what, I'm more than willing to admit being wrong - I've had to
do it many times over the course of my life (and I'm sure I have many
more ahead of me). :-)

But if you can give me an example where it doesn't work, that's
infinitely more useful (to me and the OP) than just questioning
whether or not it works. I've used the above code many, many times in
production code and on numerous platforms. I have yet to see it not
work. Does that make me *absolutely* sure? No, but let's just say...
confident. :-)

Well, IIRC, there's nothing in the C standard that prevents an
implementation to box the integers.

That's technically true but see below. The C standard doesn't say a
lot of things ... for example, it does not say you can't implement
integers as lines of dancing elephants.


Assume that 0x12345678 is stored as:
+--+--+--+--+--+
|78|12|34|56|78|
+--+--+--+--+--+
(for example, there's a type tag 0x7 for integer, a size 0x4<<1 and a
bit = 0 for some garbage collector or anything else). Then your
function will return true, when obviously the bytes are really stored
in big endian, with boxing.

Now, if you restrict yourself to implementations running on 32-bit
machines with 8-bit char with unboxed 2-complement integers, ok, it
will work. You're just lucky this kind of machine represent 99.999%
of the chips sold. (In the above example, we'd have sizeof(int)==5,
assuming a 8-bit char).

The C standard is somewhat less than consistent and hard to reason
about ... particularly where pointers, type conversions and characters
are concerned. The whole notion of characters and strings in C was an
afterthought. C89/C90 is the least restrictive of the existing
standards, but even there I think your example would be
non-conforming.

First, C89 does seem to require 2's complement format - it's not
stated anywhere but the need is implicit in the integer promotion
rules ($3.2.1.2).

As for your tagged integer:

C89 specifies that sizeof() returns # of bytes and sizeof(char) == 1
($3.3.3.4). So char == byte. Though the bit-width of a byte is left
implementation dependent, this means that chars are atomic values
which could not have a separate tag.

The pointer casting rules ($3.3.4) specify that "It is guaranteed that
a pointer to an object of a given alignment may be converted to a
pointer to an object of the same alignment or a less strict alignment
and back again; the result shall compare equal to the original
pointer". char* is the least restrictive pointer type and so the int*
cast to a char* would not change the address.

char is defined to be an integer type ($3.2.1.5,6). The section on
integral type conversions ($3.2.1.2) says "when an integer is demoted
to an unsigned integer with smaller size, the result is the
nonnegative remainder on division by the number one greater than the
largest unsigned number that can be represented in the type with
smaller size. When an integer is demoted to a signed integer with
smaller size, or an unsigned integer is converted to its corresponding
signed integer, if the value cannot be represented the result is
implementation-defined."

Finally, the assignment operator ($3.3.16.1) specifies that "if the
value being stored in an object is accessed from another object that
overlaps in any way the storage of the first object, then the overlap
shall be exact". Thus the value represented by the bits of the
integer that are overlapped by the char must be preserved. Since a
char is an integer type, that value will be an integer.

Though nothing explicitly says an integer can't have a tag, it seems
to me that the char* cast from the integer's address could not legally
point to the integer's tag, but could only point to the integer
itself.

YMMV.
George
--
for email reply remove "/" from address
.

Relevant Pages
Loading