Do unnamed bit-fields have well-defined semantics?

Question

Is the following code guaranteed to terminate normally and successfully?

#include <assert.h>

struct foo_s {
    union {
        struct {
            unsigned a : 10;
            unsigned   : 6;
        };
        struct {
            unsigned   : 10;
            unsigned b : 6;
        };
        struct {
            unsigned   : 10;
            unsigned c : 6;
        };
    };
};

int main () {
    struct foo_s f;
    f.a = 0;
    f.b = 1;
    assert(f.a == 0);
    return 0;
}

While answering a different question, the possibility was raised that assignment to a named bit-field in a structure that also contains an unnamed bit-field may cause arbitrary data to be written to those bits. C.11 §6.7.2.1 ¶12 states:

A bit-field declaration with no declarator, but only a colon and a width, indicates an unnamed bit-field.

My reading of this is that an unnamed bit-field is just a regular bit-field, with the only difference being the value in those bits cannot be obtained directly by name. Is an implementation allowed to extrapolate from that using "as-if" logic and assign arbitrary data in those bits?

Answer 1

Yes, I think an implementation may write arbitrary bits to an unnamed bit field. I think footnote 126 merely states the intention why unnamed bitfields of width larger than 0 were introduced:

An unnamed bit-field structure member is useful for padding to conform to externally imposed layouts.

So basically unnamed bit-fields have the same semantic as padding bits. You just can't rely upon their contents.

Allowing the implementation to basically ignore an unnamed bit-field when writing to an adjacent named bit-field a greatly eases the handling of that field a. The current value of the unnamed field doesn't have to be read and the write can be done atomically in one go. Just as for padding bits that might be contained in the structure.