Why and how unsafe C ++ bit fields?

Question

I met a lot of comments on various issues related to bit fields stating that bit fields are not portable, but I could never find a source explaining why.

In nominal terms, I would assume that all bit fields are simply compiled with variations of the same code with a bitrate, but obviously there should be more than that, or there would be no such fierce hostility to them.

So my question is , what makes bit polls not portable?

Answer 1

Bit fields are not portable in the same sense that integer fields are not portable. You can use integers to write a portable program, but you cannot expect to send the binary representation of int as it is to the remote machine and expect it to interpret the data correctly.

This is due to the fact that 1. the word lengths of the processors are different, and because of this, the sizes of integer types are different (the length of 1.1 bytes can also differ, but these days it is rarely found outside of embedded systems). And because 2. the byte order of bytes is different for different processors.

These problems are easily overcome. A custom sequence number can easily be converted to a consistent sequence number (a large sequence number is the de facto standard for networking), and the size can be checked at compile time, and integer types of a fixed length are currently available. Thus, integers can be used for network communications if these details are taken care of.

Bit fields are based on regular integer types, so they have the same problems with byte order and integer sizes. But they have even more implementation of this behavior.

• All about the actual details of placing bit fields in a class object

  • For example, on some platforms, bit fields do not intersect bytes, on others -
  • In addition, on some platforms, bit fields are packed from left to right, on others from right to left

• Be it char, short, int, long, or long long bit fields that are not explicitly signed or not signed, signed or not signed.

Unlike byte ordering, it is not trivial to convert “everything about the actual distribution details” to canonical form.

In addition, although the byte order depends on the processor architecture, the details of the bit fields depend on the compiler developer. Thus, bit fields are not portable for communication even between separate processes on the same computer, unless we can guarantee that they were compiled using one (or binary compatible) compiler.

---

TL DR bit fields are not a portable way of communication between computers. Integers are also not, but their intolerance is easy to circumvent.

Answer 2

Bit fields are not portable in the sense that the order of the bits is undefined. Thus, a bit with index 0 in one compiler may well be the last in another compiler.

This prevents the use of bit fields in applications, such as switching bits in memory-mapped hardware registers.

But you will see that the equipment supplier uses bit fields in the code that they issue (for example, a microchip). This is usually because they also release the compiler with it or are intended for a single compiler. For example, in the case of microchips, a license for their source code obliges you to use their own compiler (for 8-bit budget devices)

The link pointed to by @Pharap contains a fragment of the norm (C ++ 14) related to this unspecified order: is-there-aa-portable-alternative-c-bitfields