4 ms·
> The point of writing code is having the computer do the thing you want. Correct. We definitely agree here. Most importantly, we didn't talk about the specifi
by Kamq 3y ago
> The point of writing code is having the computer do the thing you want.
Correct. We definitely agree here. Most importantly, we didn't talk about the specification at all in this sentence. The behavior of the computer is what we care about. And UB only exists in the spec, it's not a thing compilers or computers do (it's an absence of specification about what a theoretical compiler would do).
> If there's no predictable outcome, then it should never be done.
I also agree here. But, with a particular compiler there is almost always a predictable outcome.
> BTW, the outcome can also change depending on optimization level.
And here, I think you're actually being too conservative. It can change with much more than just the optimization level. If you're doing intentional UB, you'd want to freeze not only your optimization level, but your entire flag set. And changing any of them could lead to months of debugging and fixing things.
This trade-off is almost never worth it. But I maintain that the "almost" belongs in that sentence.
- dale_glass 3y ago> I also agree here. But, with a particular compiler there is almost always a predictable outcome. It's potentially variable depending on other things involved, like system headers you might be including, and system updates. > And here, I think you're actually being too conservative. It can change with much more than just the optimization level. If you're doing intentional UB, you'd want to freeze not only your optimization level, but your entire flag set. And changing any of them could lead to months of debugging and fixing things. Well, isn't that a pleasant prospect there. As somebody who reviews PRs my answer to anything along those lines is: over my dead body. > This trade-off is almost never worth it. But I maintain that the "almost" belongs in that sentence. Okay, I'll grant you it's a fine idea if you want to sabotage a project and drive the other people to madness. Which if you're being paid for it may be actually illegal. Otherwise, I still go with "never". If you need to do something this bizarrely specific, if it's worth doing at all, then it's time to do it in assembly, where you can do any random weird thing you want without the compiler getting in your way.
- Kamq 3y agoI mean, just as an example, if you're working on a weird embedded system (so you can't really change compilers) where certain parts that are UB in the spec are guaranteed to have certain behavior? Additionally assuming function pointers are the same size as void *, which isn't guaranteed by the spec, when you're working on platform specific code. Although they may start optimizing that one at some point.