Bit-fields and sequence points

Question

For an implementation that packs f0 and f1 into the same byte, is the program below defined?

struct S0 {
       unsigned f0:4;
       signed f1:4;
} l_62;

int main (void) {
       (l_62.f0 = 0) + (l_62.f1 = 0);
       return 0;
}

I am interested in the answer for C99 and for C11 if there is reason to think that it is different there.

In C99, all I found was 6.5:2:

Between the previous and next sequence point an object shall have its stored value modiﬁed at most once by the evaluation of an expression. [...]

It is not clear for me what consequences this paragraph has on the program above.

Based on a large number of randomized tests, most compilers appear to generate code where the two assignments do not interfere.

Those parts of the standards give me headaches. My current reading is that the intention is that it is UB (for instance it is clear in C11 that modifying the two fields in two threads is a course is not synchronised), but the language in 6.5 forget to mention bit-field like in other places where bit-fields have a special handling. — AProgrammer, Feb 05 '12 at 18:40
@AProgrammer: The above code has a clear logical meaning (treat the writes as though the occur sequentially, in either order) and there is no reason why a compiler whose author isn't being obtuse shouldn't generate code that produces that behavior in the single-thread case. Can you suggest any plausible reason why the authors of the Standard might have intended for it to be UB? — supercat, Nov 01 '17 at 22:11

score 3 · Accepted Answer · answered Feb 05 '12 at 20:43

C11 considers adjacent named bit fields to be part of the same memory location. Such bit fields are not guaranteed to be updated atomically, in other words if one update is not sequenced explicitly before the other the behavior is undefined. 3.14 memory location then also has a detailed explanation of when two fields can be considered being in different memory locations, thus updates to them can be considered independently.

If you would modify your structure

struct S0 {
       unsigned f0:4;
       int :0;
       signed f1:4;
} l_62;

such that there is this bizarre "memory location separator" between the two bit fields, your code would be guaranteed to be fine.

For C99 the case seems to be more complicated, there is not such a detailed concept of memory location. In a recent discussion on the linux kernel mailing list there was a claim that generally for all pairs of bit fields there would be a guarantee of atomicity when updating any of them. The starting point of that discussion was a case where gcc polluted a non-bit field neighboring a bit field in an unexpected way leading to spurious crashes.

Modifying the same memory location is a data race in C11, that's sure. But while 5.1.2.4/4 speaks of memory location, 6.5/2 speaks only of scalar objects. And I'm not sure it is an oversight. The corresponding wordings in C++ are similar, data race but apparently not UB for a single expression in a single thread. — AProgrammer, Feb 05 '12 at 20:59
@AProgrammer: It would be severely impractical on most platforms to mandate that simultaneous (different threads) writes to different bitfields in the same storage element behave in sequentially-consistent fashion. Most platforms could, for essentially zero cost, guarantee that writes of one field will not affect simultaneous reads of another, but because that wouldn't be free on all platforms the Standard does not mandate it. I see nothing to suggest that compilers shouldn't be expected to handle single-threaded cases, however. — supercat, Nov 01 '17 at 22:17

score 0 · Answer 2 · answered Feb 05 '12 at 20:03

0

The assignment here is to the struct members. The fact that they happen to share the same storage should have no effect on the logic. You have not, in fact, actually made an assignment to the same thing.

Of course, I am not a language lawyer.

answered Feb 05 '12 at 20:03

ams

24,923
4
54
75

Bit-fields and sequence points

2 Answers2