Michael said:
...
I don't think this is true. Consider that:
- integers must have a pure binary representation, which means
value bits are in order
What order? At the language level the "bit" and the "order of bits" are just
concepts. The only way to interact with "bits" and analyze their "order" is to
use bitwise or shift operators, which are also language-level constructs. There
are absolutely no requirement for the language-level "order of bits" to be in
any agreement with machine-level order of bits. Moreover, there is no
requirement for the machine to even have binary "bits". The machine itself might
be ternary. This still does not prevent the implementation from using the "pure
binary representation" (as seen by bitwise and shift operators) for representing
integers.
- you can inspect the representation of any object using a
pointer to unsigned char
You will only see the language-level representation of the type 'unsigned
char', which, in general case, has absolutely nothing to to with the
machine-level details.
Given that, try this code:
#include <stdio.h>
int main(void)
{
unsigned i, c;
unsigned char *bp1, *bp2;
if (sizeof i > 1)
{
i = 0;
bp1 = bp2 = (unsigned char *)&i;
bp1++; /* point to second byte */
bp2 += sizeof i - 1; /* point to second-to-last byte */
for (c = 0; *bp1 == 0 && *bp2 == 0; c++)
i = 1u << c;
printf("bytes have %d bits in this implementation\n", (int)c - 1);
}
return 0;
}
This works for both big- and little-endian architectures, as far as I
can see, because it tests when the shift operator alters the second
or penultimate bytes. I don't offhand see a way for a conforming
implementation (where sizeof(unsigned) > 1) to produce the wrong
answer.
...
This might work "in most (or all) cases" in practice, but it is still not
something with language-guaranteed behavior. Object 'i' is allowed to contain
padding bits, which might happen to occupy both bytes you are trying to analyze
in the above code and might happen to stay 0 for all legal values of 'i'. I.e
any attempts to modify 'i' might never change the bytes in question, thus
resulting in never-ending cycle. This is unlikely in practice, but perfectly
legal from the language point of view.
