What is the type of a bitfield?

Question

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.

An interesting about bitfields is that `int` and `signed int` have different meaning in them. Dunno if this helps. — Pubby, Oct 28 '12 at 00:20
http://stackoverflow.com/questions/2647320/struct-bitfield-max-size-c99-c — SomeWittyUsername, Oct 28 '12 at 00:21
The 'maximum size of a bit field' in question 2647320 is not directly related to this issue. — Jonathan Leffler, Oct 28 '12 at 00:42
This question is NOT about the size or range of values of a bitfield. I specifically used the `signed` keyword to avoid the implementation-defined signedness issue. The question is **purely** a matter of **what type** the lvalue `foo.x` has. — R.. GitHub STOP HELPING ICE, Oct 28 '12 at 01:16

score 5 · Answer 1 · answered Oct 28 '12 at 07:59

As Jonathan already cited, p5 clearly states what the type a bit-field has.

What you should have also in mind is that there is a special rule for bit-field arithmetic conversions in 6.3.1.1, basically stating that if an int can represent all values such a bit-field converts to an int in most expressions.

What the type would be in a _Generic should be the declared type (modulo the sign glitch), since it seems to be consensus that arithmetic conversions don't apply, there. So

_Generic((X), int: toto, unsigned: tutu)
_Generic(+(X), int: toto, unsigned: tutu)

could give you different results if X is an unsigned bit-field with a width that has all values fit into an int.

score 3 · Answer 2 · answered Oct 28 '12 at 00:34

Given that you included the signed qualifier, then the only values that can be stored in the 1-bit bit field are indeed -1 and 0. If you'd omitted the qualifier, it would be implementation defined whether the 'plain' int bit field was signed or unsigned. If you'd specified unsigned int, of course, the values would be 0 and +1.

The relevant sections of the standard are:

§6.7.2.1 Structure and union specifiers

¶4 The expression that specifies the width of a bit-field shall be an integer constant expression with a nonnegative value that does not exceed the width of an object of the type that would be specified were the colon and expression omitted.¹²²⁾ If the value is zero, the declaration shall have no declarator.

¶5 A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. It is implementation-defined whether atomic types are permitted.

¶10 A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits.¹²⁵⁾ If the value 0 or 1 is stored into a nonzero-width bit-field of type _Bool, the value of the bit-field shall compare equal to the value stored; a _Bool bit-field has the semantics of a _Bool.

¹²²⁾ While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and value bits) of a _Bool may be just 1 bit.

¹²⁵⁾ As specified in 6.7.2 above, if the actual type specifier used is int or a typedef-name defined as int, then it is implementation-defined whether the bit-field is signed or unsigned.

The footnote 125 points to:

§6.7.2 Type Specifiers

¶5 Each of the comma-separated multisets designates the same type, except that for bitfields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int.

I didn't ask about the range of values. I asked what type the lvalue has. This matters for how it interacts with `_Generic`, and in other obscure ways like `?:` operator weirdness. — R.. GitHub STOP HELPING ICE, Oct 28 '12 at 01:17
It has type `signed int`, doesn't it — in your example. And if you'd specified (plain) `int`, the type would be implementation defined. But the type is the type specified in the declaration of the bit field. `_Bool` if you specified `_Bool`, otherwise, whatever integer type you specify. I'm not sure if I'm missing something or you're over-cerebrating (or both). — Jonathan Leffler, Oct 28 '12 at 02:19
I'm just a little bit troubled by the concept that you can have an lvalue of type `int` that cannot be used to faithfully store and retrieve any value of type `int`. Conceptually, it seems like the type should be "signed bitfield of width 1" or similar, but C has no such "type", so I suppose the type of the lvalue really is `int`... — R.. GitHub STOP HELPING ICE, Oct 28 '12 at 02:33

Richard Hansen · Answer 3 · 2013-07-20T06:36:20.053

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 this.

chux - Reinstate Monica · Answer 4 · 2016-10-13T20:09:33.527

... the actual type makes a difference in C11 with _Generic

The results of how 1 compiler treats the bit field types is shown below.

The 8-bit and 32-bit fields match the usual suspects.

What is the type of a 1-bit bitfield? As others have cited, its "name" is not clearly specified, but it is not any of the expected standard types.

This does not cite a specification, but does demonstrate how a respected compiler interpreted the C spec.

GNU C11 (GCC) version 5.3.0 (i686-pc-cygwin)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3

#define info_typename(X) _Generic((X), \
  _Bool: "_Bool", \
  unsigned char: "unsigned char", \
  signed char: "signed char", \
  char: "char", \
  int: "int", \
  unsigned : "unsigned", \
  default: "default" \
  )

#define TYPE_NAME(t) { printf("%s\n", info_typename(t)); }
#include <stdio.h>

int main() {
  struct {
    signed int x1 :1;
    signed int x8 :8;
    signed int x32 :32;
    _Bool b;
    signed char sc;
    char c;
    unsigned char uc;
    int i;
    unsigned u;
  } foo;
  TYPE_NAME(foo.b);
  TYPE_NAME(foo.sc);
  TYPE_NAME(foo.c);
  TYPE_NAME(foo.uc);
  TYPE_NAME(foo.i);
  TYPE_NAME(foo.u);
  TYPE_NAME(foo.x1);
  TYPE_NAME(foo.x8);
  TYPE_NAME(foo.x32);
}

Output

_Bool
signed char
char
unsigned char
int
unsigned
default           (int:1)
signed char       (int:8)
int               (int:32)

Note with -Wconversion and the below code, I get this warning. So that is at least what one compiler calls its small bit field type: unsigned char:3.

warning: conversion to 'unsigned char:3' from 'unsigned int' may alter its value [-Wconversion]

  struct {
    unsigned int x3 :3;
  } foo;
  unsigned u = 1;
  foo.x3 = u; // warning

score 2 · Answer 5 · answered Oct 28 '12 at 10:19

2

The type of a bit-field is:

bit-field of type T

where T is either _Bool, int, signed int, unsigned int or some implementation-defined type.

In your example, foo.x is of type: bit-field of type signed int.

This is different than signed int because the two types don't share the same constraints and requirements.

For example:

/* foo.x is of type bit-field of type signed int */
struct { signed int x:1; } foo; 

/* y is of type signed int */
signed int y;                     

/* valid, taking the size of an expression of type signed int */
sizeof y;

/* not valid, taking the size of an expression of type bit-field
 * of signed int */
sizeof foo.x;  

/* valid, taking the address of a lvalue of type signed int */
&y;            

/* invalid, taking the address of a lvalue of type bit-field
 * of signed int */
&foo.x;

answered Oct 28 '12 at 10:19

ouah

142,963
15
272
331

1

This is what I'd like to believe, but I can't find any language in the standard that defines such a thing as "bit-field of type T". In fact, the specification of the constraints on `&` say nothing about the *type* of the expression; they refer to the *object* which the lvalue designates, and require that it not be a bit-field. – R.. GitHub STOP HELPING ICE Oct 28 '12 at 16:32
And to be more accurate it should be something like *bit-field of type `T` and of width `n`*. In DR#120 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_120.html regarding bit-fields C Committee say about this declaration `struct S { unsigned bit:1; };` that `bit` *can be informally described as unsigned int : 1* – ouah Oct 28 '12 at 17:17

Steve Siegel · Answer 6 · 2014-07-22T01:26:31.593

The C11 Standard states in 6.7.2.1p5:

A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.

This is a constraint, meaning, if a program declares a bit field with a type that does not fall into one of the categories above, a diagnostic must be printed.

However it then goes on to say in 6.7.2.1p10:

A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits.

I believe what they mean is that, while you must declare the bit field with something like signed int x:n, the type of the lvalue expression foo.x is some other signed integer type, call it T. T is a signed integer type consisting of n bits and must comply with the constraints on all signed integer types given in Sec. 6.2.6. But T is not necessarily compatible with the standard signed integer type named signed int. (In fact, the only situation in which it is possible for T to be compatible with that standard type is if n happens to equal the number of bits in a signed int.)

Unfortunately, the Standard does not provide any means to name the type T, so I can't see how it can be used in a _Generic, at least, not in a portable way. Specific implementations of the C language may provide a mechanism to name this type, but the Standard does not force them to.

score 0 · Answer 7 · edited Oct 28 '12 at 00:37

0

I would suspect that this would depend on:

The compiler
Optimization settings
The maximum number of bits in the bit field

edited Oct 28 '12 at 00:37

Jonathan Leffler

730,956
141
904
1,278

answered Oct 28 '12 at 00:37

cowboydan

1,062
7
15

For the given information, there is nothing left to the compiler, the optimization settings, or the maximum number of bits in the bit field. If the `signed` had been omitted, then it would have 'implementation defined' behaviour (so it would vary by compiler), but optimization level would not be a factor (unless the implementation defined that its behaviour depended on the optimization level, I suppose, but that's pretty unlikely), and the maximum number of bits is still not a factor. – Jonathan Leffler Oct 28 '12 at 00:40
@Jonathan You're right. I believe I was thinking it would have been analogous to the case of "what is the underlying type of an enum?" – cowboydan Oct 28 '12 at 10:30

What is the type of a bitfield?

7 Answers7

§6.7.2.1 Structure and union specifiers

§6.7.2 Type Specifiers

Linked