Defect Report #431Previous Defect Report < - > Next Defect Report
Submitter: Douglas Walls
Submission Date: 2013-02-21
Reference Document: N1675
Date: April 2014
Subject: atomic_compare_exchange: What does it mean to say two
structs compare equal?
184.108.40.206 The atomic_compare_exchange generic functions
Atomically, compares the value pointed to by object for equality with
that in expected, and
if true, replaces the value pointed to by object
with desired, and if
false, updates the value in expected with the
value pointed to by object.
When object is an atomic
struct type and expected is
non-atomic struct type. What does it mean to compare two struct
Where does the C standard define what it means for two objects of struct
type to be equal?
220.127.116.11 NOTE 1 gives an example using memcmp on how the test for
equality might be defined. But that is non-normative.
But the padding bytes in a struct have unspecified values (18.104.22.168p6)
22.214.171.124 The memcmp function, footnote 310 reminds us that the contents
of padding in a struct is indeterminate.
Even integers can have padding bits, whose values are unspecified
A similar issue probably occurs for Atomic union types.
Suggested Technical Corrigendum
Either define equality of objects of struct type, add a restriction
use of atomic structs as arguments for the atomic_compare_exchange
or note that atomic_compare_exchange generic functions for objects of
struct type results in undefined behavior.
Apr 2013 meeting
Oct 2013 meeting
- There is no sentiment to define equality for structs.
- 7.17.6 lists atomic types required to have the same size and alignment as the corresponding direct type. Other atomic types may have differing size and alignment as per 6.2.5p27.
- 126.96.36.199p5 states that any access to an atomic struct or union member is undefined behavior and as such so would atomic_compare_exchange since it requires access.
There are several points that need addressing.
The original intention of the atomics design was to allow memcmp and memcpy (with suitable synchronization) be a common implementation for all _Atomic objects.
This practice, however, would lead to undefined behavior for implementations that have padding bits for integer representations.
For implementations that choose larger representations for some _Atomic types, there would need to be at least one larger type specific implementation of atomic_compare_exchange compared to what might be possible to implement in common for all types. This seems to imply that an implementation must supply something akin to a type generic implementation of atomic_compare_exchange. Type generic macros as applied to _Atomic is the subject of
A proposal to address these issues has been solicited.
Apr 2014 meeting
The proposed resolution from N1803 was withdrawn since there are implementations choosing to represent atomic non-lock-free types with extra state and hence a larger size.
Structure compare will result in undefined behavior.
A new paper to address this DR has been solicited
Previous Defect Report < - >
Next Defect Report