Re: gcc warn when pointers not checked non-null before de-referencing.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 18/06/2021 05:16, Xi Ruoyao wrote:
> On Thu, 2021-06-17 at 21:44 +0100, Jonny Grant wrote:
>>
>>
>> On 16/06/2021 18:59, Segher Boessenkool wrote:
>>> On Wed, Jun 16, 2021 at 02:01:05PM +0100, Jonny Grant wrote:
>>>> I guess a separate static analyser would do it, GCC is more
>>>> focused on compilation so I shouldn't ask for it to have so many
>>>> features it can't support.
>>>
>>> -fsanitize=undefined already catches null pointer dereferences, is
>>> that
>>> enough for your case?
>>>
>>>
>>> Segher
>>
>> Hello
>> Thank you for the suggestion, yes, I had used that before. I did just
>> check, it's runtime checks. I had hoped for something at compile time.
>> warning for every function that didn't check pointer for NULL before
>> de-referencing.
> 
> There is no way to do this.
> 
> int foo(struct dev *dev)
> {
>     int r = sanitize_input(dev);
>     if (r)
>         return r;
> 
>     bar(&dev->id);
>     return dev->id->result;
> }
> 
> While there is no way to know the behavior of `sanitize_input` (it may
> be defined in another TU), there is no way to tell if `foo` has done "a
> proper non-null check".

Yes, this is a good point, could only check the file that is being compiled.

> 
> And this "warning" does not make any sense.  It's perfectly legal for a
> function to assume the input is not null and the caller should guarantee
> it.  Adding a non-null check in every function is just paranoid.  This
> really looks like a suggestion from some professors who don't program at
> all, but unfortunately teach C and tell their own misconcept of
> "defensive programming" everywhere.

We were taught to be careful what we pass to functions, and careful what we accept in functions, feels appropriate.

While I can see that for developer builds, a NULL dereference and core dump would allow a developer to investigate. assert is just as good assert(NULL != ptr);

We'd rather have stability and logging of errors than a core dump. Especially on embedded systems that need to guarantee safety. It's easy enough to check for NULL and check the bounds of buffers etc before using. Asserts would trigger in a debug build.

I know GCC is a compiler, not a static analyser, so I'll probably run cppcheck

Kind regards
Jonny



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux