3 ms·
Bitfields are used a lot when you have constrained resources, in my case in LTE/5G both on modem and bts sides. Every struct's field takes as much as it needs t
by ithinkso 4y ago
Bitfields are used a lot when you have constrained resources, in my case in LTE/5G both on modem and bts sides. Every struct's field takes as much as it needs to and you leave rest as 'reservedX'. You never know when a new feature will have to be implemented and few more bits will be needed for some new field.
Without bitfields the code would be absolutely filled with bit-access macros decreasing readability and screwing with IDE's indexers and static analyzers big time
Not to mention the pain it would be to refactor/reorder/change fields sizes which is relatively painless with bitfields
- zozbot234 4y agoThe drawback though is that you can't reference individual fields by pointer. You basically need to write the equivalents of OOP getters and setters to really keep the code tidy. The compiler can't plan for such things on its own, not across multiple compilation units at any rate.
- ithinkso 4y agoThis is a valid and a main drawback of bitfields but in this context bit-access macros would be even worse since you would have pointers to a random uint32 within a struct and good luck keeping track where's what
- ncmncm 4y agoThat is not, in fact, the main drawback of bitfields. The main drawback of bitfields is that they work in your tests and fail in the field.
- ithinkso 4y agoCould you share the details (and compilers) of the issues you had because I'm actually kinda curious. From my experience most of the bugs were just a 'normal' bugs i.e. human errors when writing and those were fixable by just figuring out what was implemented incorrectly. About 2% on a bts side were cache coherency issues because we had a multicore system without hardware coherency, so imagine, and similarily 2% were hardware issues on a modem side due to race conditions or whatever - harder to fix so workarounds. But miscompilation? x86 host tests are used to separate wheat from the chaff but the only tests anyone cares about, before commit, are on target On modem side I remember one, maybe two if you push it, issues with miscompilation but it wasn't at all related to bitfields but the compiler was doing some stupid shit with register allocations
- ncmncm 4y agoThere are a lot of different C compilers (not so many C++), dozens of ISAs (although not as many as before) and ABIs (ditto) and many, many thousands of implementations of ISAs and ABIs, all done with widely varying degrees of attention to detail. There are myriad places for mistakes to manifest. Caches, interrupt behavior, and sleep modes are favorite places for implementation bugs. But bitfields are a place ordinary programmers might still encounter them. Anybody used to working with buggy one-off chip designs knows all about this. But most programmers are insulated from most bugs. The warning is for them.
- unnah 4y agoAre there other parts of the C language you are avoiding in such an environment, or is it just bitfields? I suppose in any case you'll be using C89 instead of newer language revisions.
- ncmncm 4y agoThere are of course plenty of things people write that have undefined behavior. I personally never code in C anymore; lately I am using C++17. Compiler optimizers are way, way more reliable than back when I used C.
- nomel 4y ago> You basically need to write the equivalents of OOP getters and setters to really keep the code tidy. I thought that was the entire purpose of the bitfield, to give you a clean (visual and operations) way to access the field: mybitfield.fieldname = value