[cfe-dev] Unwanted warning on assigning negatives to unsigned bit-fields

Iurii via cfe-dev cfe-dev at lists.llvm.org
Sun Jul 17 11:12:39 PDT 2016

Hi everybody,

I'm suffering from an annoying warning. Here's an example to quickly reproduce it:

    #include <stdio.h>
    #include <stdint.h>
    #include <inttypes.h>

    typedef union _bf
            uint32_t field1:2;
            uint32_t field2:30;
        } fields;
        uint32_t raw;
    } bf;

    int main(int argc, char *argv[])
        printf("0x%" PRIx32 "\n"
               "0x%" PRIx32 "\n",
                ((bf){ .fields.field1 = -1 }).raw, //Warning
                ((bf){ .raw = -1 }).raw );         //No warning
        return 0;

Compilation: clang -std=c99 -m32 -O2 -o test test.c

Result: test.c:19:37: warning: implicit truncation from 'int' to bit-field changes value from -1 to 3

Could someone, please, explain me, why the warning is produced? The C99 standard is very clear about the behaviour
with respect to the value of field1 (the value of raw after assigning to field1 is implementation-defined, but that's
a different story), and it is unambiguous: paragraph 2
"if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum
value that can be represented in the new type until the value is in the range of the new type" paragraph 9:
"A bit-field is interpreted as a signed or unsigned integer type consisting of the specified number of bits"

So field1 is an unsigned integer consisting of 2 bits. The maximum value that it can store is 2^2-1 . In order to
assign -1 to field1 2^2-1+1 must be added to -1. The result is therefore well-defined to be 3. So as long as assigning
-1 to any standard unsigned integer does not produce any warning, I see no reason behind producing it for unsigned
bit-fields. Especially because this is the most convenient way to set all bits in a bit-field. A single-bit bit-field
would be a somewhat special case for assigning -1, but I'd prefer to not have the warning in this case as well.

Kind regards

More information about the cfe-dev mailing list