I want a safe C. If that means I have to deal with fewer available optimizations, I'm all for that! That's why I wrote two's-complement arithmetic with unsigned types and why I actually have bounds checks on my array accesses in my code.
That means I would gladly take a compiler that could not allocate local variables in registers.
Or even better, just do a bounds check. The standard does not preclude storing a raw pointer and a length together. Why couldn't the compiler do something like that and do a bounds check?
(Yes, the compiler would have to use its own version of libc to make that happen, but it could.)
In other words, I want correct code first, performant code second. I'll take the performance hit for correct code.
People claim that exploiting UB gives 1-2% speedup and that that's important. What they conveniently leave out is that you only get that speedup when your code has UB, which means that you only get that speedup when your code has a bug in it.
Fast wrong code is bad. Very bad. Correct code, even if slower, is an absolute must.
That means I would gladly take a compiler that could not allocate local variables in registers.
Or even better, just do a bounds check. The standard does not preclude storing a raw pointer and a length together. Why couldn't the compiler do something like that and do a bounds check?
(Yes, the compiler would have to use its own version of libc to make that happen, but it could.)
In other words, I want correct code first, performant code second. I'll take the performance hit for correct code.
People claim that exploiting UB gives 1-2% speedup and that that's important. What they conveniently leave out is that you only get that speedup when your code has UB, which means that you only get that speedup when your code has a bug in it.
Fast wrong code is bad. Very bad. Correct code, even if slower, is an absolute must.