4 ms·
Print x twice. Not all “side effects” care about order. Better yet, define an order for parameter evaluation.
by Filligree 5mo ago
Print x twice. Not all “side effects” care about order.
Better yet, define an order for parameter evaluation.
- poppadom1982 5mo agoYou're missing the point. Volatile forces two loads of a value that may have changed in the middle. So the value of "x" may depend on the time/order of load.
- hmry 5mo agoWhy is that missing the point? Loading it twice, possibly with different values, is the intended behavior. It's only undefined because the C spec doesn't specify the order of the loads (unlike most other languages which have a perfectly well-defined order for side effects in a single expression).
- rowanG077 5mo agoWhat you are describing is implementation defined behavior. Using that is perfectly safe and reasonable. Undefined means this programs is malformed.
- hmry 5mo agoNo I'm just repeating what the original comment said, which is that it's explicitly UB: "5.1.2.4.1 says any volatile access - including just reading it - is a side effect. 6.5.1.2 says that unsequenced side effects on the same scalar object (in this case, x) are UB. 6.5.3.3.8 tells us that the evaluations of function arguments are indeterminately sequenced w.r.t. each other." If function arguments were sequenced with respect to each other, it wouldn't be a problem. But actually, maybe the original comment is wrong. Presumably "indeterminately sequenced" and "unsequenced" mean different things, although I don't have a copy of the standard at hand to check.
- AnimalMuppet 5mo agoWhich is, if I understand correctly, the entire point of volatile. Don't use it if you don't want that behavior. And in fact, in the example given, if there is something (another thread or whatever) that can change the value of x, then you don't know what either number will be. Well, in that circumstance, without volatile, it may print the same number both times, but you still don't know what the number will be (unless the read gets optimized away entirely).
- chuckadams 5mo agoIf that behavior is the entire point, then I think the bigger point is that the spec should reflect that and not call it undefined.
- voakbasda 5mo agoI suspect that many undefined behaviors reflect the inability of the standard committee to come to a consensus on the nuances involved. “Punt to the implementers” is a way to allow every tool vendor to select their own expected behavior in those cases.
- MarkusQ 5mo agoThen it should be "implementation defined" rather than "undefined".
- chowells 5mo agoYou seem to be operating under the assumption "undefined behavior" means "the compiler authors can decide what to do." That's not what it means. It means "any program that causes this behavior to be triggered is not a valid C program, the programmer knows this and did not submit an invalid program, and the programmer explicitly prevented this from happening elsewhere in ways automated analysis cannot detect. Proceed with compilation knowing this branch is impossible." The spelling for compiler authors getting to choose a behavior is "implementation defined", as the other comment mentions.
- HelloNurse 5mo agoThere is an easy way to take control: read the volatile variable only once. volatile int x = 5; ... int y=x; printf("%d in hex is 0x%x.\n", y, y);