On Tue, Jun 22, 2021 at 06:08:30PM +0300, Laurent Pinchart wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> On Tue, Jun 22, 2021 at 05:31:53PM +0300, Dan Carpenter wrote:
> > The v4l2_subdev_alloc_state() function returns error pointers, it
> > doesn't return NULL.
>
> It's funny you send this patch today, I've been thinking about the exact
> same issue yesterday, albeit more globally, when trying to figure out if
> a function I called returned NULL or an error pointer on error.
>
> Would it make to create an __err_ptr annotation to mark functions that
> return an error pointer ? This would both give a simple indication to
> the user and allow tools such as smatch to detect errors.
>
If you have the cross function DB enabled then Smatch can figure out if
it returns error pointers or NULL. The big problem is that Smatch works
on the precompiled code and doesn't understand ifdeffed code.
I haven't pushed all the Smatch checks. I told someone last month, I'd
give them a month to fix any bugs since it was their idea. But I'll
push it soon.
#if IS_ENABLED(CONFIG)
function returns error pointer or valid
#else
struct foo *function() { return NULL; }
#endif
I believe that there are also people who use a two pass Coccinelle
system where they make a list of functions that return error pointers
and then check the callers.
The Huawei devs find a bunch of these bugs through static analysis but
I don't know which tools they are using.
Today, I accidentally introduced a bug by converting a call that can
"in theory/the future return error pointers" but also returns NULL at
the end of a list. I thought it was only supposed to be checked for
NULLs. Fortunately Colin King found it right away. That was just
sloppiness on my part :/ and it's pretty rare to find code like that.
regards,
dan carpenter
