This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 117b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-08-11
2146. Scalar object vs memory location in definition of “unsequenced”Section: 6.10.1 [intro.execution] Status: CD4 Submitter: Jens Maurer Date: 2015-06-22[Adopted at the February, 2016 meeting.]
According to 6.10.1 [intro.execution] paragraph 15,
If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, and they are not potentially concurrent (6.10.2 [intro.multithread]), the behavior is undefined.
Should this refer to “memory location,” which also encompasses contiguous bit-fields, as the definition of data races in 6.10.2 [intro.multithread] does? For example,
struct S {
int x : 4;
int y : 4;
int z : 4;
};
void f(int, int, int);
int g(int, S&);
int main(int argc, char ** argv) {
S s = { argc, argc+1, argc+2 };
f(++s.x, g(++s.y, s), ++s.z);
}
Proposed resolution (February, 2016):
Change 6.10.1 [intro.execution] paragraph 15 as follows:
...If a side effect on a scalar object memory location (6.8.1 [intro.memory]) is unsequenced relative to either another side effect on the same scalar object memory location or a value computation using the value of any object in the same scalar object memory location, and they are not potentially concurrent (6.10.2 [intro.multithread]), the behavior is undefined. [Note: The next section...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4