https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #30 from Konrad Rosenbaum <konrad at silmor dot de> ---
(In reply to Andrew Pinski from comment #28)
> (In reply to Wilhelm M from comment #26)
> > As you can see in my opening bug report, there is no nullptr reference nor
> > dereferencing a pointer with value 0.
>
> Yes but as I mentioned by the time the warning happens, the IR has lost
> information if the constant came from a null pointer or from some other
> constant that the user used. So a heuristic needs to be used and the idea
> was it would be the lower bytes by default and that the lower bytes would be
> defined by a "page size" and that is how the naming of the option happened.
To be honest, this sounds like a missing feature or even a design bug:
shouldn't the IR be aware of what original address (type) a pointer/array
originated from?
If it makes a difference whether I access a[70] or a[700000000] then the
heuristic is not very helpful. If a useful option has a completely unintuitive
name that is also a problem.
Null pointers usually derive from nullptr, NULL or the integer constant 0. I
think it would be worth a flag or two to mark code pathes that transmit real
null pointers or offsets to real null pointers. Anything derived from a
non-zero integer is something that the programmer bears full responsibility for
- if he wants to aim at his foot, let him!
Even if something derives from integer 0 (as opposed to nullptr or NULL), there
is a chance that it was something that is intended (on the MCU I'm currently
using this is the register that sets the first 8 GPIO pins) - usually
"volatile" will be a good indicator of that, because memory mapped registers
are always volatile.
A few examples I can think of:
struct MyStruct { int a,b,c; };
auto *nps = (MyStruct*)nullptr; // -> originates from a nullptr, definitely a
problem!
auto *npi = &nps->c; // -> still derived from nullptr, still a problem!
MyStruct myvar;
auto *vps = &myvar ; // -> dereferences a real variable, definitely not a
problem
auto *vpi = &vps->c; // -> still not a problem
auto *sps = (MyStruct*)0x101; // -> static address, very likely not a problem
or at least the programmer's problem, not the compiler's
auto *spi = &sps->c; // same here
auto *xps = (MyStruct*)0x00; // -> static address, but 0x00 -> probably nullptr
auto *xpi = &xps->c; // -> derived from probably nullptr -> probably a problem
struct VMyStruct { volatile int a,b,c; };
auto *yps = (VMyStruct*)0x00; // -> static null address, but has volatile
members, may or may not be problematic
auto *ypi = &yps->c; // -> derived from static null address, but access is
volatile, it's the programmer's problem, no warning
auto *zps = (VMyStruct*)NULL; // NULL=((void*)0) -> derived from non-volatile
pointer to 0, count it like nullptr!
No heuristic at the point of use will be able to properly catch and categorize
those. There will have to be some flags that get passed along with the
(changing) pointer value.
Even then there should be a way to tell the compiler whether (SomeType*)0 is a
null pointer or a pointer to a legitimate memory location. Can pointer values
have attributes?
The question that remains is: is this change worth it and might it help to
catch other problems?
