4 ms·

What kind of mechanism is there in place to prevent any compiler from just replacing your main() function with formatting /dev/sda? That's nothing to do with t

What kind of mechanism is there in place to prevent any compiler from just replacing your main() function with formatting /dev/sda? That's nothing to do with the language, that's always on the compiler. Nothing stops the compiler from taking even correctly-specified code and doing whatever it wants.

ivanbakel 2y ago
That's a rathee obtuse response. You can typically operate under the assumption that the compiler works correctly. The question of the GP was - what prevents the compiler from (correctly) exploiting UB to change the program behaviour from the desired one? If the Linux devs want to rely on their compilers' output, they have to somehow be obeying the contract around UB.
- shawnz 2y ago
  I think the more reasonable assumption is that the practical needs of the biggest users will probably trump what any specification demands. The thing stopping the compiler from doing dangerous behaviours in response to commonly abused UB is obviously that people wouldn't use the compiler if it did that. Just like how the thing stopping the compiler from doing dangerous behaviours in response to spec-legal code is that people wouldn't use it if it did that.
gosub100 2y ago
he was referring to the U in "UB".
NobodyNada 2y ago
"Undefined behavior could format your hard drive" is kind of a meme, but it's a meme with a point. A lot of programmers have the idea that UB is "what the hardware does", that when you go outside the bounds of the C program you just have to think at the machine code level to figure out what will happen. But that's not the reality with a modern compiler; what with all the levels of analysis, optimization, and transformation that happen between source code and machine code, the effects of undefined behavior are extremely unpredictable and often inconsistent and nondeterministic. The point of "undefined behavior could format your hard drive" is that if your code exhibits UB, the compiler is not required to translate it "correctly", and you can't make an attempt to reason about the behavior of the program. See also: "What Every C Programmer Should Know about Undefined Behavior": https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html https://blog.llvm.org/2011/05/what-every-c-programmer-should...

ivanbakel 2y ago

That's a rathee obtuse response. You can typically operate under the assumption that the compiler works correctly. The question of the GP was - what prevents the compiler from (correctly) exploiting UB to change the program behaviour from the desired one? If the Linux devs want to rely on their compilers' output, they have to somehow be obeying the contract around UB.

shawnz 2y ago
I think the more reasonable assumption is that the practical needs of the biggest users will probably trump what any specification demands. The thing stopping the compiler from doing dangerous behaviours in response to commonly abused UB is obviously that people wouldn't use the compiler if it did that. Just like how the thing stopping the compiler from doing dangerous behaviours in response to spec-legal code is that people wouldn't use it if it did that.

gosub100 2y ago

he was referring to the U in "UB".

NobodyNada 2y ago

"Undefined behavior could format your hard drive" is kind of a meme, but it's a meme with a point. A lot of programmers have the idea that UB is "what the hardware does", that when you go outside the bounds of the C program you just have to think at the machine code level to figure out what will happen. But that's not the reality with a modern compiler; what with all the levels of analysis, optimization, and transformation that happen between source code and machine code, the effects of undefined behavior are extremely unpredictable and often inconsistent and nondeterministic. The point of "undefined behavior could format your hard drive" is that if your code exhibits UB, the compiler is not required to translate it "correctly", and you can't make an attempt to reason about the behavior of the program. See also: "What Every C Programmer Should Know about Undefined Behavior": https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html https://blog.llvm.org/2011/05/what-every-c-programmer-should...