4 ms·

> If signed int arithmetic on the hardware wraps around upon overflow, then take that into account when optimising and don't assume it can't overflow. This is h

by clarry 9y ago

> If signed int arithmetic on the hardware wraps around upon overflow, then take that into account when optimising and don't assume it can't overflow. This is how C programmers want the language to work; Don't speak for all of us. Some of us may take the language for what it is, instead of assuming it to be a "high level portable assembler" which it is not, but which a particular implementation of it may be, thanks to the standard leaving much up to the implementation. It is this same leeway that (thankfully) allows smart optimizing compilers that can generate performant code for programs that are not omgwtf-optimized at the source level. And it is this same leeway that allows very simplistic, naive implementations that do not go out of their way to perform crazy analysis to try and warn you about some corner case of undesirable behavior your code might hit. You're right that it is the compilers can and need to change to accommodate different types of users. But I don't think every compiler should just go back to being a 1991 compiler; not every compiler needs to accommodate every user.

runevault 9y ago
They CAN accommodate all users, just have compile time options you can enter in your make file/on the command line/etc to say what level of bounds checking/etc you want compiled into your code. Hell that way even within a given project you can choose "this library I'm nervous about so I'll eat the hit on bounds checking".
- pjmlp 9y ago
  They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Checking.html#Object-Size-Checking https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-Checker-builtins.html#Pointer-Bounds-Checker-builtins https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in-android.html https://android-developers.googleblog.com/2017/04/fortify-in...
  - wahern 9y ago
    The performance culture isn't just C. Far from it. Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. The article for this thread literally says, "For many use cases ASan is the better choice because it has much less overhead." IME Valgrind does a _much_ better job of detecting memory issues, partly because ASan only detects issues directly triggered in the code that you compile, whereas Valgrind can detect memory issues directly triggered by external code, but indirectly caused by your code.
    - eridius 9y ago
      > Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. Citation please? I thought Rust used guard pages, and that stack probing was something that it was moving towards, not something that was being ripped out.
      - comex 9y ago
        Rust used guard pages, but was still vulnerable to attacks based on jumping over the guard page, which is the same issue that Stack Clash exploited in C programs. The ideal fix for that is stack probing, which Rust is indeed moving towards. However, in the past, Rust had a different fix: it would add a bit to all function prologues that explicitly checked for running out of stack space - based on LLVM split stack support, and a remnant of when (even further in the past) Rust actually used split stacks. The explicit check also protected against jumping over the guard page, but was much more expensive than stack probing, and also caused issues with embedded use cases. The plan was to replace it with stack probing, but things dragged on and it was removed before the replacement was ready.
    - pjmlp 9y ago
      > The performance culture isn't just C. Far from it Sure, but it is where it is more visible, specially micro-optimizing code as it is being written, without validating if it really matters to the application's use case with a profiler. The school of systems programming languages from Algol side, was that correctness was much more relevant than pure performance, Algol dialects for systems programming already had Rust like unsafe blocks in the mid-60's. In Burroughs B5500 the administrator could enable which applications with unsafe modules were allowed at all to be executed, 10 years before C was invented.

by clarry 9y ago

runevault 9y ago

They CAN accommodate all users, just have compile time options you can enter in your make file/on the command line/etc to say what level of bounds checking/etc you want compiled into your code. Hell that way even within a given project you can choose "this library I'm nervous about so I'll eat the hit on bounds checking".

pjmlp 9y ago
They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Checking.html#Object-Size-Checking https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-Checker-builtins.html#Pointer-Bounds-Checker-builtins https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in-android.html https://android-developers.googleblog.com/2017/04/fortify-in...
- wahern 9y ago
  The performance culture isn't just C. Far from it. Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. The article for this thread literally says, "For many use cases ASan is the better choice because it has much less overhead." IME Valgrind does a _much_ better job of detecting memory issues, partly because ASan only detects issues directly triggered in the code that you compile, whereas Valgrind can detect memory issues directly triggered by external code, but indirectly caused by your code.
  - eridius 9y ago
    > Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. Citation please? I thought Rust used guard pages, and that stack probing was something that it was moving towards, not something that was being ripped out.
    - comex 9y ago
      Rust used guard pages, but was still vulnerable to attacks based on jumping over the guard page, which is the same issue that Stack Clash exploited in C programs. The ideal fix for that is stack probing, which Rust is indeed moving towards. However, in the past, Rust had a different fix: it would add a bit to all function prologues that explicitly checked for running out of stack space - based on LLVM split stack support, and a remnant of when (even further in the past) Rust actually used split stacks. The explicit check also protected against jumping over the guard page, but was much more expensive than stack probing, and also caused issues with embedded use cases. The plan was to replace it with stack probing, but things dragged on and it was removed before the replacement was ready.
  - pjmlp 9y ago
    > The performance culture isn't just C. Far from it Sure, but it is where it is more visible, specially micro-optimizing code as it is being written, without validating if it really matters to the application's use case with a profiler. The school of systems programming languages from Algol side, was that correctness was much more relevant than pure performance, Algol dialects for systems programming already had Rust like unsafe blocks in the mid-60's. In Burroughs B5500 the administrator could enable which applications with unsafe modules were allowed at all to be executed, 10 years before C was invented.