17

What is maximal bit width for bit struct field?

struct i { long long i:127;}

Can I define a bit field inside struct, with size of bitfield up to 128 bit, or 256 bit, or larger? There are some extra-wide vector types, like sse2 (128-bit), avx1/avx2 (256-bit), avx-512 (512-bit for next Xeon Phis) registers; and also extensions like __int128 in gcc.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
osgx
  • 90,338
  • 53
  • 357
  • 513
  • For long bit fields, you may want to investigate std::bitset declared in . As for bit limitations, I suggest first reading your compiler documentation for limitations as these are generally more strict than those imposed by the language standard. – Thomas Matthews Apr 15 '10 at 16:59
  • @Thomas Matthews, what are generic limitations of max bit field size? Does standard define some upper limit? – osgx Apr 15 '10 at 17:01

4 Answers4

23

C99 §6.7.2.1, paragraph 3:

The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the number of bits in an object of the type that is specified if the colon and expression are omitted. If the value is zero, the declaration shall have no declarator.

C++0xa §9.6, paragraph 1:

... The constant-expression shall be an integral constant expression with a value greater than or equal to zero. The value of the integral constant expression may be larger than the number of bits in the object representation (3.9) of the bit-field’s type; in such cases the extra bits are used as padding bits and do not participate in the value representation (3.9) of the bit-field.

So in C you can't do that at all, and in C++ it won't do what you want it to.

Stephen Canon
  • 103,815
  • 19
  • 183
  • 269
  • 7
    You just forgot to mention that in C99 the only types that are guaranteed to work are `_Bool`, `signed int` and `unsigned int`. In particular the use by the OP of `long long` is implementation specific. – Jens Gustedt Nov 23 '10 at 09:45
  • 1
    @JensGustedt is the restriction by standard also? If so, somewhere near 6.7.2.1? – WhozCraig Oct 28 '12 at 00:31
  • @WhozCraig: That restriction is paragraph 4 of 6.7.2.1: "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." – icktoofay Jan 27 '13 at 23:57
  • 1
    @JensGustedt: If the implementation supports bit-field types other than those listed, the restriction in paragraph 5 still applies. `long long i:127;` must trigger a diagnostic if the implementation doesn't support `long long` bit fields. If it does support them, then it must be diagnosed if `CHAR_BIT * sizeof (long long) < 127` (which is true for every implementation I've seen, but not mandated). This comment applies only to C, not to C++. – Keith Thompson Jun 13 '14 at 19:48
3

The C++ Standard sets no limits on the size of a bit-field, other than that it must be greater or equal to zero - section 9.6/1. It also says:

Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. ]

Which I suppose could be taken to indicate some sort of maximum size.

This does not mean that your specific compiler implementation supports arbitrarily sized bit-fields, of course.

  • @osgx I don't know - I never, ever use bit-fields in my own code, so it's not an issue for me. –  Apr 15 '10 at 17:51
  • 2
    @osgx: GCC supports wacky bitfield sizes. An oversized bitfield (even `char a : 10;` simply wastes the extra bits. – Potatoswatter Apr 15 '10 at 18:42
2

Typically, you cannot allocate more bits than the underlying type has. If long long is 64 bits, then your bitfield is probably limited to :64.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175
  • If i will use mmx/sse2 type (128 or 256 bits), can I allocate 3/4 of it as bitfield? – osgx Apr 15 '10 at 17:20
  • 1
    These are not *integral types* as far as the compiler is concerned, so they have no bearing effect on the maximum width of a bitfield you can declare. – Dale Hagglund Apr 15 '10 at 18:10
1

Since the values of bit-fields are assigned to integers, I'd assume that the largest bit-field value you can use is that of the size of intmax_t.

Edit:

From the C99 Spec:

6.7.2.1 Bullet 9:

A bit-field is interpreted as 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.

6.7.2.1 Bullet 10:

An implementation may allocate any addressable storage unit large enough to hold a bit- field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

Paul Ellis
  • 106
  • 3
  • sample from my question: long long i. I can use up to 64 bits of this longlong as bitfiled, which is greater than int – osgx Apr 15 '10 at 17:19
  • These quotes do not support your assumption… – Potatoswatter Apr 15 '10 at 18:43
  • What part of the spec does not support my assumption? "A bit-field is interpreted as a signed or unsigned integer type." That implies that the largest bit-field size is the size of the largest integer type. I included bullet 10, because my interpretation of that bullet is that any sized storage unit (larger than zero bits) can have a bit field. It appears that this supports the OP's desire to add bit-fields to "extra-width vector types" as long as the bit-field sizes are smaller than intmax_t. If I am interpreting something wrong, please correct me. – Paul Ellis Apr 16 '10 at 00:24