5 ms·

+1 for -fno-delete-null-pointer-checks But actually, what I'd rather like is -fno-optimise-based-on-undefined-behaviour.

brandmeyer 10y ago
-fno-delete-null-pointer-checks In my particular case, I'm programming in a microcontroller environment where there is ordinary RAM at the NULL address. Dereferencing NULL therefore doesn't halt the program at all.
- teddyh 10y ago
  Your compiler, or rather your architecture definition supplied to the compiler, is broken. NULL should be an invalid pointer value — it need not actually be memory address 0. (The explicit constant 0 in a pointer context should be automatically translated by the compiler into this special invalid pointer value.) There have been several such architectures already, so this should not present an insurmountable problem.
- yrro 10y ago
  AIUI, this code is not affected: X *foo = ...; if (foo) foo->bar(); But this code will be: X *foo = ...; foo->bar(); if (foo) { ... } Since foo is dereferenced unconditionally, the compiler is allowed to assume that it will not be null in the above code, and therefore the test on the third line to determine whether foo is null or not is useless and can be omitted.
  - iso-8859-1 10y ago
    Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
    - caf 10y ago
      The real case where it matters is where the "if (foo) { ... }" test happens in a function that's been inlined into the caller, but not all the callers do the foo->bar() dereference. So it's only being removed in some cases.
    - brandmeyer 10y ago
      There used to be a fairly broad warning (-Wunreachable-code), but it caused so many false positives and false negatives that it was removed.
- Kristine1975 10y ago
  Same thing in say the Linux kernel, where gcc removing a NULL pointer check actually created a vulnerability: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/
  - brandmeyer 10y ago
    Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.
astrange 10y ago
Try "-fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks" and then see if your program gets slower. That won't nearly get everything, but loop optimization in C relies on undefined behavior a lot of the time, so you'll get to see how much you need it.

brandmeyer 10y ago

-fno-delete-null-pointer-checks In my particular case, I'm programming in a microcontroller environment where there is ordinary RAM at the NULL address. Dereferencing NULL therefore doesn't halt the program at all.

teddyh 10y ago
Your compiler, or rather your architecture definition supplied to the compiler, is broken. NULL should be an invalid pointer value — it need not actually be memory address 0. (The explicit constant 0 in a pointer context should be automatically translated by the compiler into this special invalid pointer value.) There have been several such architectures already, so this should not present an insurmountable problem.
yrro 10y ago
AIUI, this code is not affected: X *foo = ...; if (foo) foo->bar(); But this code will be: X *foo = ...; foo->bar(); if (foo) { ... } Since foo is dereferenced unconditionally, the compiler is allowed to assume that it will not be null in the above code, and therefore the test on the third line to determine whether foo is null or not is useless and can be omitted.
- iso-8859-1 10y ago
  Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
  - caf 10y ago
    The real case where it matters is where the "if (foo) { ... }" test happens in a function that's been inlined into the caller, but not all the callers do the foo->bar() dereference. So it's only being removed in some cases.
  - brandmeyer 10y ago
    There used to be a fairly broad warning (-Wunreachable-code), but it caused so many false positives and false negatives that it was removed.
Kristine1975 10y ago
Same thing in say the Linux kernel, where gcc removing a NULL pointer check actually created a vulnerability: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/
- brandmeyer 10y ago
  Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.

astrange 10y ago

Try "-fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks" and then see if your program gets slower. That won't nearly get everything, but loop optimization in C relies on undefined behavior a lot of the time, so you'll get to see how much you need it.