This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

how to stop bit-field sign extension


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]