[jylam]

> Turning on the so-called “optimizer” breaks this code because current C “optimizers” bizarrely enough can change the semantics of C code in often unpredictable ways without making any performance improvements. This is permitted by the C Standard for reasons that strike me as not well thought out, but let’s pass over this sad situation for the moment.

the C Standard has a thing called "undefined behavior", and this person is running right into it with their invalid pointer arithmetic. So the result is undefined, and could be anything, including embedding the Doom source code.

[benj111]

>could be anything

Why do people say this. I mean it may be technically correct, but not reasonable by any stretch. If I put a spelling error or miss a semi colon in my code it may be legal for the compiler to do anything but that isn't reasonable. We rightly expect compilers to pick up on and point out spelling errors why do we not expect the same for UD.

Or do you also tell programmers not to make any errors because the compiler doesn't have to warn you about even the most obvious ones?

If I overflow a signed integer, I expect that to be on me, and depending on the context I could check for overflow after the fact. That isn't a licence for the compiler to do what it damn well wants, and practically speaking it doesn't really matter anyway. What processors in the past 30 years have done anything funky on integer overflow or has weird signed integers?

C gives you enough rope to hang yourself. It isn't required for the compiler to tie the noose and pull the lever.

[vyodaiken]

It's interesting how often people repeat this argument as if it were persuasive. The compiler developers and Standards writers made an engineering decision which is hard to justify so most people who support it don't even try.

[suprjami]

If your C isn't arbitrarily running Doom at unpredictable times, are you even doing it right?