This exact problem exists today if someone takes code from the Linux kernel that is compiled with things like -fno-strict-aliasing. Undefined Behaviour makes programs unpredictable in the first place, given that you can't reasonably ensure you're not triggering it. I would expect a lot more people to use friendly-c (or simple-c or yes-this-is-how-your-cpu-works-c) than standard c.
As he notes, people who need the undefined behaviour-induced optimisations are in the minority.
Most programmers already write C like it is "friendly-C".
Re:Proposal for a Friendly Dialect of C
by jjnoakes on Wednesday August 27, 2014 @08:00PM
(#8235307)
There's an obvious solution to this: have friendly-c compilers accept some declaration silently in a source file:
!dialect friendly-c
Such code would also fail if passed to tools like lint, and would result in warnings or worse when loaded in IDEs. The incredible C toolchain built over the decades is one of C's biggest advantages; friendly-c cannot afford to lose even 10% of it.
So make it a #pragma.
Or some coder is used to friendly C, uses aliasing, memcpy and wrapping arithmetic without thinking twice. Then he's asked to work on some project building with a regular C toolchain. Gun is cocked and pointed at the foot.
Those problems only occur because friendly C is a dialect of C, you don't get those drawbacks if you tell devs to use Rust or whatnot, because the difference between Rust and C is obvious, unlike friendly C and C.