2

I was trying to find a reason why I should not write

struct bitfield { signed foo:4; unsigned bar:2; };

instead of specifying verbosely

struct bitfield { signed int foo:4; unsigned int bar:2; };

As the size of each member of the bitfield is explicitly specified after the colon, could there be any drawbacks?

Does it matter if I use char, short, long, long long? Must the number of specified bitfield bits probably always be smaller than the width of the declaration type?

Found some related questions:

The answers range from

  • don't use any other type than (signed/unsigned) int or _Bool and
  • _Bool, signed int, unsigned int, or some other implementation-defined type. (C99 6.2.7.1 (4) )

In this context: what may this unspecific some other implementation-defined type be like, and what other drawbacks may arise from my choice in this place?

Improve this question
1
  • 1
    I am sadly not the right person to answer this, but the question made me curious and I browsed the web a bit. C90,C99 and C++ all have differing definitions on what types are allowed, and to make matters worse, it seems some compilers use the type to determine the minimum size of the structure (ie, a long long foo:1 could result in a larger structure then a int foo:1) bytes.com/topic/c/answers/… had interesting info on the topic Commented Apr 22, 2012 at 19:37

2 Answers 2

Reset to default
3

"Sometimes", and "Yes"

C99 requires that the width expression "not exceed the number of bits in an object of the type that is specified" so if too small a type is used, the code will either not compile or at least not be portable. See §6.7.2.1 (3).

Regarding the updated third question and the general, "exactly what are the consequences?" issue, the things that could be affected are: portability, alignment, and padding. The standard gives clear specifications only for the first. Without bitfields, it's usually possibly to arrange alignment and padding based on predicting what the compiler would do to generate optimally aligned values. Although it is not guaranteed, it seems like in some environments using something like short will save memory due to the reduced alignment and padding that result.

One possible approach to achieving the occasionally conflicting goals of exact layout and portability is to declare the in-memory data structures without bit fields, perhaps using <stdint.h> types. Then, if you want to use a bit field to decode something, assign the in-memory source object to a temporary variable that's a union of a bit field and a bit-specific type, or, deliberately violate the type punning rules by casting a pointer. (Linux does this all over the place.)

A better way is probably to just avoid bit fields.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

In both versions of your code, the width is explicit; it's the width of signed and unsigned int. signed is just an alias for int, and so is signed int. Likewise, unsigned is an alias for unsigned int. Lone signed and unsigned are not modifiers but type names in themselves.

Improve this answer

3 Comments

Indeed, but what I've asked is why I would want to choose short over int or similar.
No, I think the signed here is not redundant. An int bitfield can have the semantic of an unsigned type. J.3.9 marks this as implementation defined behavior.
Indeed, I forgot that ugly special case.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.