3 ms·
> 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
by 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.