Today's “this language is broken” courtesy of @ch3root
https://godbolt.org/g/H8d0I2
-
-
oh, good point. I was going to tell
@CopperheadSec that a proper null pointer sanitizer would amount to auto-inserting that “if” -
A pointer arithmetic sanitizer could trap on arithmetic from NULL because that's undefined. That would cover the rest.
End of conversation
New conversation -
-
-
Note that gcc does the same as clang without the null pointer check (b/c the code is UB), but does right with check added
-
BTW a nice thing in searching interesting testcases for tis-interpreter is that you are free use any UB in them:-)
-
I made the mistake, going in the other direction—tis-interpreter to GCC—of forgetting GCC doesn't have a duty to warn.
-
I agree w/
@RichFelker GCC isn't doing wrong: it assumes malloc can only return 0 for this input, so the program always runs into UB -
No. Just replace SIZE_MAX by SIZE_MAX / 4 * 3 and add -m32 and you get a genuine compiler bug.
-
well 32-bit GCC still assumes that malloc has to return 0 for this input.
-
You say it's not documented but GCC devs kindly & consistently remind anyone who reports this as a bug that GCC assumes this.
-
it's not WELL documented. There should be a prominent warning about using GCC with Glibc on 32-bit platforms. (RMS would intervene)
End of conversation
New conversation -
-
-
It's written this way mainly because tis-interpreter is 64-bit only. On 32-bit and with glibc you can do it for real.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.