Re:What Every C Programmer Should Know About Undefined Behav...
by mpweiher on Thursday January 05, 2017 @11:30AM
(#13328477)
> Here lies madness.
Nah. You're looking at it the wrong way. You are saying madness lies in going there. We don't have to "go there". We can simply not leave there. Not doing something is easy. In fact, it's my secret super-power. If you want, I'd be happy to teach you.
Re:What Every C Programmer Should Know About Undefined Behav...
by haberman on Thursday January 05, 2017 @12:17PM
(#13329040)
Compilers already have these optimizations. Doing nothing would be leaving those optimizations in.
If what you want is a straightforward translation of C into machine code, there is always -O0.
Re:What Every C Programmer Should Know About Undefined Behav...
by mpweiher on Thursday January 05, 2017 @03:22PM
(#13330991)
> Compilers already have these optimizations.
git co <previous-hash>
You're welcome!
Re:What Every C Programmer Should Know About Undefined Behav...
by haberman on Thursday January 05, 2017 @05:11PM
(#13331909)
You're the person who wants this. Maybe you should do that? Also make sure you're willing to give up support for newer language standards, CPU architectures, and countless bugfixes (even C++98 support was getting pretty noticeable bugfixes in GCC 10 years ago).
Here lies madness. What optimizations are not allowed exactly? Strict aliasing? Assuming dereferenced pointers are not null? Assuming all array accesses are always in bound? Assuming that integers don't wrap? Assuming that allocated memory is not accessed after a free? Reusing function frame slots of variables with non overlapping lifetimes? Not laying down local variables in the most obvious way? Caching and reordering non-volatile memory accesses? Accessing local variables of functions that have returned?
I'm sure you will say obviously not allowed to the first few and obviously allowed to the last few, but at some point all of these optimizations (and more) did break some code as some point.