You're saying that you want that all entirely disabled, with pointers treated as addresses. That's asking for a whole lot more than -fno-strict-aliasing and not marking pointer arithmetic inbounds (and the latter definitely has a huge impact on important loop optimizations, etc).
-
-
Replying to @DanielMicay @filpizlo and
I'm certainly not saying that it can't be done or that it isn't useful but that you're understating how much needs to be changed and the impact of it. Memory corruption also doesn't become predictable, just *less* impacted by optimization. It's still always going to be impacted.
1 reply 0 retweets 1 like -
Replying to @DanielMicay @filpizlo and
Here's something that's undefined: accessing uninitialized data. int a; if (cond1) { a = 5; } else { if (cond2) { a = 10; } } use(a); do_other_stuff(); use(a); Lets say that cond1 & cond2. Should both calls to use(a) be guaranteed to read the same value from uninitialized data?
2 replies 0 retweets 2 likes -
Replying to @DanielMicay @jckarter and
Of course they should see the same value. Holy cow you’re throwing the easiest examples at me. It’s like you’re making my point for me: that this is easy to fix but that some people need compiler educations.
1 reply 0 retweets 2 likes -
Okay, and that also means that using MADV_FREE in malloc and elsewhere is not possible either, which is a massive performance cost. Uninitialized memory can and does change value at runtime beyond just compiler optimizations avoiding saving uninitialized data via spill / restore.
2 replies 0 retweets 4 likes -
Replying to @DanielMicay @jckarter and
You’re not going to MAD_FREE on the stack. Duh.
1 reply 0 retweets 0 likes -
That's likely glibc what is going to be doing for their stack cache since MADV_DONTNEED is a significant performance cost for their implementation, and it doesn't become a non-issue if restricted to malloc since it still means that uninitialized memory can change between reads.
1 reply 0 retweets 4 likes -
Replying to @DanielMicay @filpizlo and
Reading uninit data being undefined instead of locking it to an unspecified value permits massive optimizations like MADV_FREE and more efficient register allocation/spilling. Similarly, other memory safety issues being undefined permits optimization / freedom of implementation.
1 reply 0 retweets 5 likes -
Replying to @DanielMicay @filpizlo and
Many programs have bugs where they read data that has just been freed, but handle it being an arbitrary value. The issue is often benign with common allocators. However, with other implementations the access will fault and they crash. It's good it's not required to let it work.
2 replies 0 retweets 3 likes -
Replying to @DanielMicay @filpizlo and
Also, signed overflow being undefined rather than defined as wrapping means that more secure implementations where it traps are permitted. Passing -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow is standards compliant and used for hardening in AOSP.
3 replies 0 retweets 6 likes
Never considered that. Very good point.
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.