If it helps, anything that introduces UB for optimizations (like forbidding assuming that 'int y,x;' implies an order in memory) is also good for security.

Mainly because it lets you use systems with type-safe pointers (some acronyms are PAC, BTI, CHERI) - the regular "concrete semantics" aka "whatever current pointers let you get away with" has a lot of issues! But also because compiling with extra security is not popular if it causes performance regressions.

> anything that introduces UB for optimizations (like forbidding assuming that 'int y,x;' implies an order in memory) is also good for security.

[...]

> But also because compiling with extra security is not popular if it causes performance regressions.

Yes. So while UB could theoretically be (in some cases) good for security, in practice it is absolutely not, because no tooling exists to introduce runtime checks light enough to be used in production. So UBs can and do reveal and/or amplify latent bugs, or even introduce new ones if new UB are introduced in new specifications.

PAC/BTI are definitely used in production, UBSan is fast enough to ship in production if you want, and there's more tools being used that I can't talk about here.