3 ms·
The compiled code is also a lot slower. https://www.cis.upenn.edu/acg/softbound/ https://www.cis.upenn.edu/acg/softbound/
by Ded7xSEoPKYNsDd 9y ago
The compiled code is also a lot slower. https://www.cis.upenn.edu/acg/softbound/ https://www.cis.upenn.edu/acg/softbound/
- yorwba 9y agoOnly if you want to define the undefined behavior to be safe. If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. My point is that you can write your compiler spec to make explicit how exactly various kinds of UB are actually implemented, which then allows you to program to that spec and know that e.g. your overflowing bounds check is not completely eliminated from the program, but instead compiled into the machine instructions you had in mind. If a compiler is verified to conform to such a specification, unintended changes in handling UB will be very obvious, since the spec will have to be changed to make the verification go through.
- pcwalton 9y ago> If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. Yes, it does, because some optimizations now become invalid. For example, a compiler would no longer allowed to delete a provably out-of-bounds write. This happens all the time. I don't think there's a lot of practical value in changing the definition of some kinds of undefined behavior to "memory corruption" (however defined) in the first place.