[PATCH v2] param: add error check to __dev_add_param()
Sascha Hauer
s.hauer at pengutronix.de
Thu Jan 29 23:44:53 PST 2015
On Thu, Jan 29, 2015 at 07:47:31PM +0900, Masahiro Yamada wrote:
> Hi Sascha,
>
> On Thu, 29 Jan 2015 10:32:12 +0100
> > > > > @@ -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?
> >
> > Yes, please.
>
>
> I did that in v3.
>
>
> > >
> > > 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..)
> >
> > Note we also have xstrdup which crashes barebox on out of memory. This
> > is usually the right thing to do when it's known that the allocation is
> > small.
> >
>
> I stopped and I have been thinking about it.
> I hesitate a bit to replace it with xstrdup(). I feel like being lazy.
>
> So, I did not do this in v3.
The name of the parameter can be passed in by the user via the 'global'
command, so using strdup instead seems like a good idea here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list