Re: [PATCH v2] param: add error check to __dev_add_param()

[Masahiro Yamada <yamada.m@jp.panasonic.com>]

Hi Sascha,

On Thu, 29 Jan 2015 10:06:22 +0100
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Thu, Jan 29, 2015 at 11:46:53AM +0900, Masahiro Yamada wrote:
> > If the argument, name is given with NULL, it would be probably
> > unexpected behavior.  It should fail rather than register the
> > NULL-named parameter.
> > 
> > If strdup() fails with out-of-memory, it should also fail
> > with -ENOMEM.
> > 
> > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
> > ---
> > 
> > Changes in v2:
> >   - Fix the condition of returning -ENOMEM
> > 
> >  lib/parameter.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/parameter.c b/lib/parameter.c
> > index 71262c4..02a89bb 100644
> > --- a/lib/parameter.c
> > +++ b/lib/parameter.c
> > @@ -130,6 +130,13 @@ static int __dev_add_param(struct param_d *param, struct device_d *dev, const ch
> >  	if (get_param_by_name(dev, name))
> >  		return -EEXIST;
> >  
> > +	if (!name)
> > +		return -EINVAL;
> 
> Name is used already two lines above so barebox will already be crashed
> before this triggers.
> 
> Besides, I normally don't like these checks. dereferencing NULL pointers
> means you get a backtrace showing you what went wrong. Returning an error
> means adding code which in this case makes dev_add_param just fail
> silently because the return value often is not checked.
> 

OK, then how about dropping this -EINVAL check?

I think the -ENOMEM check below is still useful.
( strdup() returns NULL also when NULL is passed,
but in that case this line cannot be reached.
The problem is that is not apparent at a glance..)


Best Regards
Masahiro Yamada


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox