[PATCH v1] gpudev: return EINVAL if invalid input pointer for free and unregister
Morten Brørup
mb at smartsharesystems.com
Thu Dec 2 14:56:08 CET 2021
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Thursday, 2 December 2021 14.01
>
> > > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > > Sent: Thursday, 2 December 2021 08.19
> > >
> > > 01/12/2021 22:37, Tyler Retzlaff:
> > > > On Wed, Nov 24, 2021 at 06:04:56PM +0000, Bruce Richardson wrote:
> > > > > if (ret < 0 && rte_errno == EAGAIN)
> > > >
> > > > i only urge that this be explicit as opposed to a range i.e. ret
> == -
> > > 1
> > > > preferred over ret < 0
> > >
> > > I don't understand why you think it is important to limit return
> value
> > > to -1.
> > > Why "if (ret == -1)" is better than "if (ret < 0)" ?
> >
> > Speaking for myself:
> >
> > For clarity. It leaves no doubt that "it failed" is represented by
> the return value -1, and that the function does not return errno values
> such as
> > -EINVAL.
> >
>
> But why '< 0' gives you less clarity?
> Negative value means failure - seems perfectly clear to me.
I disagree: Negative value does not mean failure. Only -1 means failure.
There is no -2 return value. There is no -EINVAL return value.
Testing for (ret < 0) might confuse someone to think that other values than -1 could be returned as indication of failure, which is not the case when following the convention where the functions set errno and return -1 in case of failure.
It would be different if following a convention where the functions return -errno in case of failure. In this case, testing (ret < 0) would be appropriate.
So explicitly testing (ret == -1) clarifies which of the two conventions are relevant.
More information about the dev
mailing list