On Mon, Jan 28, 2013 at 11:57:39AM +0100, Florian Vaussard wrote: > Le 28/01/2013 10:57, Thierry Reding a écrit : > >On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote: > >>Hello, > >> > >>Le 28/01/2013 09:45, Peter Ujfalusi a écrit : > >>>hi Thierry, > >>> > >>>On 01/26/2013 06:40 AM, Thierry Reding wrote: > >[...] > >>>>>+{ > >>>>>+ return pwm->chip->can_sleep; > >>>>>+} > >>>>>+EXPORT_SYMBOL_GPL(pwm_cansleep); > >>>> > >>>>Would it make sense to check for NULL pointers here? I guess that > >>>>passing NULL into the function could be considered a programming error > >>>>and an oops would be okay, but in that case there's no point in making > >>>>the function return an int. Also see my next comment. > >>> > >>>While it is unlikely to happen it is better to be safe, something like this > >>>will do: > >>> > >>>return pwm ? pwm->chip->can_sleep : 0; > >>> > >> > >>Ok. And what about: > >> > >>BUG_ON(pwm == NULL); > >>return pwm->chip->can_sleep; > > > >I don't think we need that. In case pwm == NULL, dereferencing it will > >oops anyway. So either we make it safe and return an error code, or we > >let it oops without explicit BUG_ON(). > > > > Calling this function with a NULL pointer is a programming error, so there > is no error codes for such errors. You could return -EINVAL if pwm == NULL. > I propose to return bool, and let it oops if such case happens. My point was that it will oops even if you don't use BUG_ON() so there isn't so much point in using it explicitly. Thierry
Attachment:
pgpLRxi03DOYv.pgp
Description: PGP signature