As I said, it's also ABI. Though admittedly, endianness would be encompassed by ABI, so it's all really just ABI

Not really relevant to a discussion about CPUs and compiler implementations...

Uh, that's standard C89. You know, the bit fields? Except for the "false" keyword, that's from stdbool.h and you need C99 for that to reliably exist.

It's probably tough to find a metaprogramming solution to this, for two reasons:

1. Addressing happens at the byte level, not the bit level, so a type can't begin on any bit. You'd have to do your own addressing, such as in std::bitset.

2. For now, there's no reflection in the language, so you can't really assign names to members in a general way (hello, preprocessor). A solution might be to index by type; something like the following:

struct BitA{}; struct BitB{};

using ExampleBitFields = BitFields<BitA, BitB>;

bool checkBitA(const ExampleBitFields& x) { return x[BitA{}]; }

However, this has a lot of downsides.

You can absolutely initialize bitfield members in structs, not sure where your memory is from… maybe it was broken on some specific compiler vendors/versions?

This is a c++20 feature

It is not possible to specify bitfields in a way that makes sense, is consistent with a bytewise view of memory, and is portable between big endian and little endian processors.

Say you have, for instance (using C notation)

  struct {
    unsigned one : 8;
    unsigned two : 8;
  };

The fields are supposed to be represented in memory in the same order they are declared, so one is the first byte and two is the second byte. This should have the same representation as if I declared it as two uint8_t fields. If I type pun it and load it into a register as a uint16_t then it depends on the hardware whether the low and high bytes are one and two or two and one.

It gets more tricky when you consider arbitrary bit widths.

  struct {
    unsigned u4 : 4;
    unsigned uC : 12;
  };

If the fields are allocated in order, is u4 the low bits of the first byte or the high bits? If you require it to be the low bits, then it works ok on a little endian machine, but on a big endian machine the uC field ends up split, so the 16 bit view looks like:

  CCCC4444CCCCCCCC

gcc?

MSVC does things simply, gcc does not

Try this in clang and gcc:

    #pragma pack(1)
    struct S {
        char c:1;
        char d:1 __attribute__((aligned(2)));
        char e:1;
    };
    _Static_assert(sizeof(struct S) == 1, "wrong size");

> Bit fields are portable since ages, since C89.

Wrong. N1256 (ISO C99 spec), for instance, explicitly states in 6.7.2.1.10:

  The order of allocation of bit-fields within a unit
  (high-order to low-order or low-order to high-order)
  is implementation-defined.

Look it up.

How bitfields are allocated within a byte is related, but independent from endianness.

endianness: how an array of bytes is interpreted as an integer/how an integer is layed out in memory as an array of bytes.

bitfield allocations: how subsequent bitfields are allocated within an integer, typically starting from least significant bit to most significant, or the other way around.

> You shouldn't rely on them for packing memory at all if you want to talk to other programs.

While the layout is indeed implementation dependent, pragmatically if you stick to using ints the layouts are portable as far as I can tell. Just like the size of ints is implementation dependent, but is reliably 32 bits on 32 and 64 bit machines.

> You can have arbitrary bit width integers as well.

This is news to me, how? AFAIK they'll only eventually make it into C23 with _BitInt(N).

...and apart from building a C++ wrapper class of course, but how would this pack with data outside the class - like the 4 + 28 bits example in the blog post.

Also IIRC when I tinkered with C/C++ bitfields, some compilers (at least MSVC I think?) didn't properly pack the bits (e.g. a single bit would be padded to a full byte, or they couldn't agree on a common size of the containing integer - e.g. one compiler packing <8 number of bits into an uint8_t, and another into a uint32_t). In the end C/C++ bitfields weren't all that useful for the use case described in the blog post, at least if portability across the three big compilers is needed (gcc, clang, msvc).

C Bitfields are fairly common in embedded code. While layout can vary across compilers and archs hardware driver writers assume a known arch and compiler. You really can't compile embedded targets with say msvs or clang. Also gcc seams to be the defacto compiler for most embedded nowadays.

>always convert to big endian when sending data over a wire

What is this awful advice. Only convert to big-endian where legacy demands it.

Most, even all of these, sound to me like cargo-culting. I certainly use multiple returns and continue statements all the time. I pass structs by value when I want to stress that they represent a value type that can / should be copied around (for example, a slice). As for the format to send data over a wire, I will either use the ntoh() / hton() macros, or move to a more standard binary format such as protobuffs.

The only thing I don't usually run into is the very topic of this article: bit fields.

The (IIRC) ELF specification explicitly recommends against using bitfields because of implementation defined layout.

The compilers often barely document exactly how they lay things out.

Yeah no, bitfields are notoriously implementation defined.

In the embedded world you often have to deal with vendor specific toolchains, and with their finicky compilers, you'd be surprised the weirdness you run into when using bitfields.

You will learn to question everything not specifically defined by the c standard.