Comments on: C99 Language Lawyer Needed

By: Derek Jones

Derek Jones — Wed, 08 Feb 2012 17:18:29 +0000

Jeroen, I am guilty of answering a modified form of the original question (which I think is defined because all the relevant wordings talk about objects and not their storage).

My explanation applies to the case of the following statement appearing in the above code:

s.f0 = s.f1;

By: Jeroen Mostert

Jeroen Mostert — Wed, 08 Feb 2012 16:01:07 +0000

Thinking a bit more, the only way you could use 6.5.16.1p3 to make adjacent bit-field assignments illegal is if you used the following interpretation:
- Adjacent bit-fields overlap each other in storage since they’re in the same storage unit; but
- This overlap is not exact because their *storage* within that unit is not the same.
This seems deliberately contrived, measuring with two yardsticks. Either contend that the overlap is exact because it’s the same storage unit, or there’s no overlap at all because the region of data storage is distinct. Either way would avoid it.

I prefer the latter interpretation because the first still poses a problem: if the bit-fields are not of the same type, assignment is still undefined because, even though the overlap is exact, the types are not compatible (the other requirement of 6.5.16.1p3). Give the poor bit-fields a break.

By: Jeroen Mostert

Jeroen Mostert — Wed, 08 Feb 2012 15:52:34 +0000

6.5.16.1p3 cannot possibly apply here because “the value being stored” is in both cases a suitably-converted 0, and not “read from another object”. Regardless of storage, the bit-fields are clearly distinct objects. This section describes the semantics of assignment, not general object access.

If we read the value from the other bit-field, but then the expression invokes UB by simple sequence point violation. If we read the value from a bit-field not involved in this expression, then the discussion about storage would apply. I think that, since bit-fields are distinct objects and hence distinct “regions of data storage” (the standard’s definition of an object) even if they also occupy the same storage unit, 6.5.16.1p3 would not invoke UB for bit-field assignments. To interpret this section otherwise would make all assignments from a bit-field to an adjacent bit-field illegal, which I’m pretty sure is not what the standard is going for.

By: Derek Jones

Derek Jones — Wed, 08 Feb 2012 15:21:05 +0000

John, this is an interesting question.

The issue here is two or more objects (e.g., bit-fields) potentially sharing the same “storage unit”

Sentence 1409/1410:
http://c0x.coding-guidelines.com/6.7.2.1.html

coupled with the the meaning of “overlaps in any way” in:

C11/C99 6.5.16.1p3
Sentence 1304: http://c0x.coding-guidelines.com/6.5.16.1.html

“If the value being stored in an object is read from another object that overlaps in any way
the storage of the first object, then the overlap shall be exact …”

Does overlap refer to storage units, just the bits allocated to the bit-field object (making the behavior well defined) or something else?

If it refers to a storage unit then the overlap would appear to be exact, making the behavior well defined.

I will ask WG14 people what they think.

By: Jeroen Mostert

Jeroen Mostert — Wed, 08 Feb 2012 06:39:01 +0000

I’m sorry. “I think I mentioned the pipeline once, but I got away with it.” For purposes of standards wrangling, though, it’s always permissible to drag in a real-world concept if it can be shown to be consistent with the standard. As an extreme example, a C11 implementation could forcibly parallelize calculations that can be parallelized according to the standard. Probably no real-world C implementation would do this, but if it’s conceivable under the standard, and it causes UB, then there’s the possibility of UB, and that was what the question’s about.

And yes, comp.std.c is not like comp.lang.c at all. If comp.lang.c is a battlefield, comp.std.c is a fencing academy. The fact that it sees vastly less traffic helps, of course.