6 ms·
What should the behavior above be defined to do?
by saagarjha 5mo ago
What should the behavior above be defined to do?
- lll-o-lll 5mo agoHCF
- JadeNB 5mo agoWhat is that?
- FabHK 5mo agoA fictitious assembly instruction (and pretty good TV series). https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing) https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing...
- SAI_Peregrinus 5mo agoHalt and Catch Fire
- saagarjha 5mo agoI have good news about what UB allows
- jeffffff 5mo agoCompilation error
- echoangle 5mo agoCouldn’t you just define that function arguments are evaluated left to right? Or just throw an error.
- saagarjha 5mo agoI meant reading the uninitialized variable
- muvlon 5mo agoThere is no uninitialized variable, I explicitly initialized it to 5. And yes indeed, C could do what Rust does and define the order of evaluation for function arguments. If the argument expressions are indeed side-effect-less, the compiler can always make use of the "as-if" rule and legally reorder the computation anyway, for example to alleviate register pressure.
- jfoks 5mo agoWhy? Just for this edge case? It could be faster and/or allow smaller code size to allow this to be undefined. Undefined is also different from "depends on the compiler", because which behavior is chosen can even depend on the circumstances, whatever code appears before and/or after it. That said, UB in code, such as this example of ordering of reads of volatile parameters being undefined, does not automatically mean that code that uses it is bad. It may very well be that the function being called doesn't misbehave either way.
- echoangle 5mo agoThat’s the point of the whole article. It’s not worth the speed gain to have a language that nobody can safely use because you can’t really prevent UB when you write it. > It may very well be that the function being called doesn't misbehave either way. The function being good or bad has nothing to do with the UB. The UB occurs before the function is called.
- Filligree 5mo agoPrint 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 ago
- tsukikage 5mo ago“Implementation defined behaviour”: compiler author chooses, and documents the choice. A lot of UB should be implementation defined behaviour instead; this would much better match programmers’ intuitions as they reason about their code - you can even see it in the comments of this post: it’s always things like “this hardware supports / doesn’t support unaligned accesses”, it’s never nasal demons.
- tardedmeme 5mo agoI told someone at a conference that UB actually means "implementation-defined, no documentation required". He started to refute me and then stopped.
- marcosdumay 5mo agoExcept that UB doesn't mean that. UB means "the developer must never write this".
- munch117 5mo agoBoth are wrong. It means "this standard does not constrain the behaviour of code that does this". It's entirely legal for implementations to have predictable behaviour, documented or not, for code that is undefined by the standard. In their quest for maxxing benchmark performance they generally choose not to, but there's really nothing in any standard that stops you from making an implementation that prioritises safety.
- tardedmeme 5mo agoEvery implementation so far has predictable behavior in all cases. Sometimes the rules for predicting it are very obscure. But it's all fully defined within the compiler's binary code. And none of them link to nasal portals.
- AlotOfReading 5mo ago