4 ms·
If you count the number of UB in the standard, then yes, 200 cases is high. There is some ongoing effort to eliminate many of them. But it should also be noted,
by uecker 2y ago
If you count the number of UB in the standard, then yes, 200 cases is high. There is some ongoing effort to eliminate many of them. But it should also be noted, that almost all of those cases are not really problematic in practice. The problematic ones are signed overflow, out-of-bounds, use-after-free, and aliasing issues. Signed overflow is IMHO not a problem anymore because of sanitizers. In fact, I believe that unsigned wraparound is much more problematic. Out-of-bounds and use-after-free can be dealt with by having good coding strategies and for out-of-bounds issues I expect that we will have full bounds safety options in compilers soon. Aliasing issues can also mostly be avoided by not playing games with types. User-after-free is more problematic (and where the main innovation of Rust is). But having a good ownership model and good abstractions also avoids most problems here in my experience. I rarely have actual problems in my projects related to this.
- GTP 2y ago> Signed overflow is IMHO not a problem anymore because of sanitizers IIRC the overflow in SHA3's reference implementation was hard to catch also for ststic analisys tools, and had the practical impact of making it easy to generate collisions.
- uecker 2y agoA sanitizer could have transformed this into a run-time trap.
- littlestymaar 2y ago> Out-of-bounds and use-after-free can be dealt with by having good coding strategies You're basically saying that every project in the wild has bad “coding strategy”… > I expect that we will have full bounds safety options in compilers soon Which will be disabled in most places because of the overhead it incurs. > But having a good ownership model and good abstractions also avoids most problems here in my experience. I rarely have actual problems in my projects related to this. It's easier said than done when you have no way of enforcing the ownership, and practically intractable when not working alone on a codebase.
- uecker 2y agoNo, I am not saying that every project in the wild has a bad "coding strategy". Some of the most reliable software I use everyday is written in C. Some of this I use for decades without every encountering a crash or similar bug. So the meme that "all C code crashes all the time because of UB" is clearly wrong. It is not intractable, in my experience you just have to document some rules and occasionally make sure they are followed. But I agree that a formal system to enforce ownership is desirable.
- littlestymaar 2y ago> So the meme that "all C code crashes all the time because of UB" is clearly wrong. It's not about crash at all, but “all software has security vulnerabilities because of UB” is unfortunately true. > It is not intractable, in my experience you just have to document some rules and occasionally make sure they are followed. If even DJB couldn't get that part perfectly I'm pretty certain you cannot either.
- davrosthedalek 2y agoNot all software is security relevant. I run a lot of large simulations. I do not care at all if that software would crash on specially prepared inputs. I do care that it's as fast as possible.
- uecker 2y agoRight and there are other ways to achieve strong security guarantees than memory safety, e.g. at the OS level by sandboxing critical operations.
- littlestymaar 2y ago1. It's much more expensive that using a memory-safe language in the first place (maybe cheaper it if you have a big codebase already, but still very expensive and not worth it at all for new code) 2. Sandbox escapes are commonplace, and not everything can even be sandboxed at all.