4 ms·

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 ap

by unwind 10y ago

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.

mpweiher 10y ago
> "do what I mean" 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.
- masklinn 10y ago
  > Well, the code is right there, there is no magic "do what I mean" needed. Just don't magically remove code that I wrote. You can already do that: use a non-optimising compiler (tcc and the like) or compile without optimisations.
- staticassertion 10y ago
  > Just don't magically remove code that I wrote. Compile with O0. > 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.
  - mpweiher 10y ago
    > Well welcome to writing C? I've been writing C for 30 years. > UB is critical to performance Not really, no. See "What every compiler writer should know about programmers or “Optimization” based on undefined behaviour hurts performance" (referenced elsewhere in this thread) http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201...
    - staticassertion 10y ago
      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.
      - mpweiher 10y ago
        Having something wrong be or become reality doesn't change it being wrong.
        staticassertion 10y ago
        Ok... so what? I don't care if you blame the compiler or the spec, and no one else should either - the end result is the same, vulnerable code.
makomk 10y ago
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.
mjevans 10y ago
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.

by unwind 10y ago

mpweiher 10y ago

> "do what I mean" 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.

masklinn 10y ago
> Well, the code is right there, there is no magic "do what I mean" needed. Just don't magically remove code that I wrote. You can already do that: use a non-optimising compiler (tcc and the like) or compile without optimisations.
staticassertion 10y ago
> Just don't magically remove code that I wrote. Compile with O0. > 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.
- mpweiher 10y ago
  > Well welcome to writing C? I've been writing C for 30 years. > UB is critical to performance Not really, no. See "What every compiler writer should know about programmers or “Optimization” based on undefined behaviour hurts performance" (referenced elsewhere in this thread) http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201...
  - staticassertion 10y ago
    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.
    - mpweiher 10y ago
      Having something wrong be or become reality doesn't change it being wrong.
      - staticassertion 10y ago
        Ok... so what? I don't care if you blame the compiler or the spec, and no one else should either - the end result is the same, vulnerable code.

makomk 10y ago

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.

mjevans 10y ago

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.