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.
Conversation
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
3
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
4
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
5
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
3
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
5
Trapping on overflow breaks lots of code that does it on purpose. Code that can’t run is more secure than code that doesn’t only in a meaningless sense.
1
That code can be fixed and the fixes are clear cut bug fixes. High quality C code is tested with ASan, TSan, UBSan, etc. and many of these issues are already being caught and fixed over time. Portable and safe C code needs to avoid relying on undefined behavior like this.
2
5
You say overflow is undefined. I say it’s defined. As a bonus CPUs say I’m right. The world needs a language that just does what the CPU does. If you don’t want that, don’t program in C.
4
2
2
C isn't defined as that language, and you're not in a position where you get to define the language. In the real world, C is deployed with various safety features taking advantage of many things being undefined and reducing portability / compatibility with those wouldn't be good.
Neither of us gets to choose how C is defined. You want to make it more permissive, and I would make it stricter and safer. Instead, the standard compromises between all the competing interests (portability, performance, safety) by giving implementations lots of freedom.
2
So, I can use a safer implementation working towards full type and memory safety. You can use a permissive implementation. The standard makes C portable to all kinds of implementations. Implementations also can and do expose assorted options for extending the language.
2
Show replies
This Tweet was deleted by the Tweet author. Learn more
Yup and every code base I’ve worked on also imposes its own rules via compiler flags and build system hacks.
How can we get people like Filip into a position where they get to define the language? Because the current security and backwards-compatibility situation is absolutely untenable.
1
I hope he's not in a position to define the language because he has repeatedly stated that he wants to make changes that would make safe implementations non-standard and incompatible unlike the status quo. He wants to roll back even the current broadly deployed safer features.
1
1
Show replies