> I think it's a bit out of line to call this malice.
I apologise, but note (warning: weasel words follow) I was careful to say it looks like malice to me, not that I have any indication that it actually was malice.
> I'm not convinced implementation-defined behavior is really any better, though. Packagers and end-users should not have to ensure that the code their compiling is "compatible" with the compiler or hardware architecture they want to use.
I think it is better, purely because then the resulting code can't simply be omitted when an integer may overflow, the code still has to be emitted by the compiler.
Right now all the worst bits of UB has to do with the compiler optimising out code. With IB replacing UB, the implementation will have to pick a behaviour and then stick with it. Much safer.
I apologise, but note (warning: weasel words follow) I was careful to say it looks like malice to me, not that I have any indication that it actually was malice.
> I'm not convinced implementation-defined behavior is really any better, though. Packagers and end-users should not have to ensure that the code their compiling is "compatible" with the compiler or hardware architecture they want to use.
I think it is better, purely because then the resulting code can't simply be omitted when an integer may overflow, the code still has to be emitted by the compiler.
Right now all the worst bits of UB has to do with the compiler optimising out code. With IB replacing UB, the implementation will have to pick a behaviour and then stick with it. Much safer.