Except Ada has UB (they used to call them bounded errors, but the semantics are basically identical), and reading the musings of ADAists[0]
> I would say, having looked at hundreds of thousands of lines of Ada, that I have had a disappointingly frequent experience in finding the UNCHECKED_CONVERSION generic used in production Ada code.
> I agree that this is often a mark of poor craftsmanship and
unhesitatingly discourage its use, but it is there
If finding potential UB in Ada programs is as simple as grepping for unchecked_conversion, then that's a big step forward compared to C, don't you think?
The claim is that it's impossible to avoid UB in real world C, but not impossible in real world $SAFERLANGUAGE, with Ada as an example. Any language that allows you to poke around in memory (a feature you need for embedded systems) will contain unsafe constructs. The question is whether you can tell by looking whether a particular piece of code is safe or not.
Compiler writers could/should start by not treating undefined behavior as blank checks.
This is so idiotic, and no, it's not a bug in Cap'n'Proto, it is very definitely a bug in the compiler (and/or the current version of the C spec. if it actually allows this).
I think the main point is that if there is a standard, an implementation should comply. If there is no standard, you have to use intuition and common sense to say what's a bug.
Different people may have different expectations, so bugs become subjective.
Ideally, there is a water-tight standard. In this case every deviation from the standard is a bug and vice versa.
> if there is a standard, an implementation should comply
Yes. However, we are talking specifically about the parts where the standard is undefined. The standard most emphatically does not require a compiler to do these crazy optimizations that remove safety critical code.
So rewriting code in order to "do what I mean" makes sense, since not doing what you mean is a bug in the language itself?
Not sure that's a very productive approach. The spec is what it is, and it's of course rather deliberately done the way it is in order to make it possible for compilers to optimize and extract more performance.
Not so much "do what I mean" as "do what the underlying hardware architecture does". For example, on pretty much any machine your code is likely to run on these days, pointer arithmetic is the same as unsigned arithmetic, and so it's quite reasonable to expect C compilers to treat it that way. The spec can't mandate this because there are some obscure historic systems where pointer arithmetic is bounds-checked in hardware or has other oddities, but people not writing code for those systems shouldn't have to deal with that.
We're seeing these new security bugs because the abuse of portability wiggle-room as a corner to intentionally cut is changing the meaning that a human is trying to convey in a logical statement.
I still assert that at the very least if logical operations are eliminated they should be verbosely enumerated in the output of the compiler.
It might also be nice if there were a way of marking a section as /security/ rather than /speed/ critical, and thus transformations on the highlighted section would be far more limited.
Well, the code is right there, there is no magic "do what I mean" needed. Just don't magically remove code that I wrote.
> spec is [..] rather deliberately done the way it is in order to make it possible for compilers to optimize and extract more performance
Yes, and it is wrong. Breaking existing programs with magic that simply removes code that is clearly there in order to eke out a bit of performance is wrong.
> Yes, and it is wrong. Breaking existing programs with magic that simply removes code that is clearly there in order to eke out a bit of performance is wrong.
Well welcome to writing C? It's been this way for a long time and that won't change - UB is critical to performance and doesn't always lead to unsafety. If you're programming in C, don't blame the compiler when your UB leads to remote code exec, you should have known what you were getting into.
C optimizers have and will optimize around UB. Feel free to call it a bug in C, the compiler, or the programmer, or the code - when you write C, when you use a common compiler, you're asking for vulnerabilities.
Thanks for the paper. It's very interesting but I think it has no real impact on my initial statement - these optimizations aren't going away, you can continue to expect problems like this vuln in the future for the same reasons.
