Alex Rivera | Logout

What is the type of a bitfield?

Asked 2012-10-28T00:14:06.130
19

I can't find anywhere in the C standard where this is specified. For example, in

struct { signed int x:1; } foo;

is foo.x an lvalue of type int, or something else? It seems unnatural for it to be an lvalue of type int since you cannot store any value of type int in it, only 0 or -1, but I can't find any language that would assign it a different type. Of course, used in most expressions, it would get promoted to int anyway, but the actual type makes a difference in C11 with _Generic, and I can't find any language in the standard about how bitfields interact with _Generic either.

c language-lawyer bit-fields c11
Edit
Report

1 Answer

3

The C11 specification certainly does not make this clear, and is perhaps deficient.

I believe that foo.x is an lvalue with type other than int, but my justification is pretty weak:

6.2.7 paragraph 1 says:

Two types have compatible type if their types are the same.

6.3 paragraph 2 says:

Conversion of an operand value to a compatible type causes no change to the value or the representation.

If foo.x is an lvalue of type int, then it would be compatible with other ints so foo.x = 5 should result in foo.x having value 5 (per 6.3p2). That obviously can't happen, suggesting that foo.x is not compatible with int, suggesting that foo.x is not an lvalue of type int.

It doesn't really make sense that foo.x isn't compatible with int. Maybe no conversion (in the 6.3.1 sense) occurs, and that foo.x obtains its value via some mechanism not discussed in the standard. Or maybe I'm misunderstanding what "arithmetic operands" means, and that 6.3.1 doesn't apply to lvalues.

There's also 6.3.1.1 paragraph 1 bullet 2, which says:

  • The rank of a signed integer type shall be greater than the rank of any signed integer type with less precision.

foo.x has less precision than an ordinary int (when used as an lvalue, not when it "is converted to the value stored in the designated object" as described in 6.3.2.1p2), so it must have a different integer conversion rank. This also suggests that it is not an int.

But I'm not sure that my interpretation is valid or matches the intention of the committee.

I would recommend submitting a defect report about thi

answered 2013-07-20T06:26:58.903

Your Answer