What does it mean to have an unsigned bit-field if sign extension
can still occur in a case such as this:
[siml4]$ cat a.c
struct foo {
unsigned int a:16;
} x;
main()
{
unsigned long long ll;
x.a = 0x8000;
ll = x.a << 16; /* (unsigned int) x.a does not help */
printf ("%llx\n", ll);
}
[siml4]$ gcc a.c
[siml4]$ a.out
ffffffff80000000
The target of the assignment is unsigned, so the result of the shift
of an unsigned bit field is evidently treated as signed.
Are unsigned semantics of bit fields supported in ANSI C?
The standard mentions that bit fields can have unsigned type,
but are unsigned bit fields then allowed 'implementation
defined' behavior (meaning the unsigned-ness can be ignored)?
Replacing the 16-bit unsigned field with unsigned short avoids
the sign extension when widening to 64 bits. So this doesn't
seem like a fundamental effect of integral promotion -- not a
consistent one, at least.
