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?
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?
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.
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.
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.
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...)
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.
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,};
A point not yet mentioned is that the standard explicitly allows for the possibility that integer representations may contain padding bits. Personally I wish the standards committee would allow a nice easy way for a program to specify certain expected behaviors, and require that any compiler must either honor such specifications or refuse compilation; code which started with an "integers must not have padding bits" specification would then be entitled to assume that to be the case.
As it is, it would be perfectly legitimate (albeit odd) for an implementation to store 35-bit long values as four 9-bit characters in big-endian format, but use the LSB of the first byte as a parity bit. Under such an implementation, storing 1 into a long could cause the parity of the overall word to become odd, thus compelling the implementation to store a 1 into the parity bit.
To be sure, such behavior would be odd, but if architectures that use padding are sufficiently notable to justify explicit provisions in the standard, code which would break on such architectures can't really be considered truly "portable".
The code using union should work correctly on all architectures which can be simply described as "big-endian" or "little-endian" and do not use padding bits. It would be meaningless on some other architectures (and indeed the terms "big-endian" and "little-endian" could be meaningless too).
