Hacker News Reader

Comment by Retr0id | Hacker News Reader

I don't think I've ever seen struct bitfields used in real code, it's almost always manual bit-masks against a numeric type, often via macros. (I assume due to portability)

View on HN

I have seen bit fields used in real code. Long ago. The reason I know it so well is that bit field updates are NOT atomic, and this caused a rare crashing bug under heavy load. Unless you read the header the code looks atomic.

S->buffer_free = 1;

This is a very serious limitation if the structure/class is being updated in a multi-threaded environment.

The Windows API uses bitfields like that in some places. I know because I was working with the display configuration API recently and found the bitfields very annoying to use through generated FFI bindings (especially because they were used in anonymous structs inside anonymous unions).

I see it decently often in embedded code for memory mapped IO registers. Other than that, I don't think I've ever seen it either.

I'm not sure portability is the reason though. I've seen it in places that have no problem spamming #define __GNU_SOURCE

This is the only place I've seen it used, and the only placed I've used it.

It's absolutely wonderful for IO.

I would be scared of using it for IO... With a struct bit field, I don't know what bit offset a field ends up with, I don't know how it gets padded, and I don't know how large the generated load and store becomes. I'd rather do the bit operations and store myself.

__attribute__((packed)) is pretty much required for this use case.

That gets rid of the padding issue, but still does little to tell me which bit corresponds to which field.

In terms of the underlying bit assingments, bitfields have been pretty safe for a very long time now, as you can assume little-endian. Just a question of bearing in mind the packing rules, not too difficult given stdint.h. I went full bitfield shortly after the time I went full size_t, about 15 years ago now.

Big-endian systems sort-of still exist (I do indeed have an Amiga, and an Atari STe, and an Xbox 360, and they all work, so they must count) - but they're only slightly less weird from a practical C programming perspective than stuff like the DSPs with CHAR_BIT==24, and Harvard architecture microcontrollers with 2-byte ints. And so you can ignore them. People that use still actually these systems will be used to it.

Yep. If I need a boolean for a struct I know I’ll want more than one. So I’ll stick an integer type that lets me OR multiple enum values (and so on).

There are some other annoyances, like not being able to inline initialize a bitfield prior to C++20, and sometimes having to use unnatural typing to get optimal packing depending on the ABI. But I've seen them used, compilers have gotten pretty good at optimizing them and can coalesce writes or tests against adjacent bitfields.

I have, e.g., in Julia's UTF-8 library (utf8proc).

Reply on news.ycombinator.com