What is wrong with this C function to find the endianness of a machine at runtime?

Question

This is what I offered at an interview today.

int is_little_endian(void)
{
    union {
        long l;
        char c;
    } u;

    u.l = 1;

    return u.c == 1;
}

My interviewer insisted that c and l are not guaranteed to begin at the same address and therefore, the union should be changed to say char c[sizeof(long)] and the return value should be changed to u.c[0] == 1.

Is it correct that members of a union might not begin at the same address?

Answer 1

I was unsure about the members of the union, but SO came to the rescue.

The check can be better written as:

int is_bigendian(void) {
    const int i = 1;
    return (*(unsigned char*)&i) == 0;
}

Incidentally, the C FAQ shows both methods: How can I determine whether a machine's byte order is big-endian or little-endian?

Answer 2

The standard says the offsets for each item in a union are implementation defined.

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. ISO/IEC 9899:1999 Representation of Types 6.5.6.2, para 7 (pdf file)

Therefore it's up to the compiler to choose where to put the char relative to the long within the union- they are not guaranteed to have the same address.

Answer 3

While your code would probably work in many compilers the interviewer is right -- how to align fields in a union or struct is entirely up to the compiler and in this case the char could be placed either at the "beginning" or the "end". The interviewer's code leaves no room for doubt and is guaranteed to work.

Answer 4

I have a question about this...

how is

u.c[0] == anything

valid given:

union {
    long l;
    char c;
} u;

How does [0] work on a char?

Seems to me, it would be equivalent to: (*u.c + 0) == anything, which would be, well, crap, considering the value of u.c, treated as a pointer, would be crap.

(Unless perhaps, as it occurs to me now, some html crap code ate an ampersand in the original question...)

Answer 5

While the interviewer is correct and this is not guaranteed to work by the spec, none of the other answers are guaranteed to work either, as dereferencing a pointer after casting it to another type yields undefined behavior.

In practice, this (and the other answers) will always work, as all compilers allow casting between pointer-to-union and pointer-to-member-of-union transparently -- much ancient code will fail to work if they did not.

Answer 6

You are correct in that the "members of a union might begin at the same address". The relevant part of the Standard is (6.7.2.1 para 13):

The size of a union is sufficient to contain the largest of its members. The value of at most one of the members can be stored in a union object at any time. A pointer to a union object, suitably converted, points to each of its members (or if a member is a bit-field, then to the unit in which it resides), and vice versa.

Basically, a start address of the union is guaranteed to be the same as the start address of each of its members. I believe (still looking for the reference) that a long is guaranteed to be larger than a char. If you assume this, then your solution should_ be valid.

* I'm still a little uncertain due to some interesting wording around the representation of integer and, in particular, signed integer types. Take a close read of 6.2.6.2 clauses 1 & 2.

Answer 7

correct me if I am wrong but local variables are not initialized to 0;

this is not better:

union {
    long l;
    char c;
} u={0,};