3 ms·

-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. Deref

-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 11y 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 11y 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 11y ago
  Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
  - caf 11y 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 11y 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 11y 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 11y ago
  Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.

teddyh 11y 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 11y 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 11y ago
Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
- caf 11y 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 11y 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 11y 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 11y ago
Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.