Bit fields are portable, in the sense that they are a part of the C language as specified in the standard (C11 section 6.7.2.1). Any compiler that fails to recognise code that uses bitfields is not standard-compliant. There's also nothing really questionable about your example, since all it does is have bitfields present.
What they probably mean is that the fields themselves may be packed unpredictably in location and order (allowed by the standard, previous ref. paragraph 11). This means that a struct with e.g. four bitfields of size 4, 12, 13 and 3 does not necessarily take up 32 bits and they won't necessarily be placed within the struct in that order; the compiler can place them where it likes. This means that the struct cannot be treated as an actual component-wise representation of an underlying binary object.
In contrast, bitmasks applied manually to integers exist exactly where you put them. If you define masks that mask out the first 4 bits, second 12 bits, etc. of an unsigned integer, the "fields" will actually apply to the bits, in order and in position (assuming you know the endianness, anyway). This makes the representation compiler-independent.
i.e. they are portable, but what they do may not necessarily be exactly what a person actually wanting to manipulate individual bits may need.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…