On Tue, 6 Jan 2004, Duncan Sands wrote:

> On Monday 05 January 2004 16:42, David Brownell wrote:
> > There are a lot of "is it null?" tests that are just pointless
> > code bloat.  It's not a big deal, but getting rid of such stuff
> > needs to start somewhere.
> 
> Hi Dave, I don't much buy the code bloat argument.  For me it's
> like this: these routines are called from device drivers.
> 
> case (1): these tests may prevent a device driver from screwing
> the USB subsystem/other drivers.  In this case they should stay.
> 
> case (2): these tests only protect device drivers from themselves.
> In that case they are probably only making device driver bugs harder
> to spot, and they should go.

I go along with Dave on this.  In my opinion, tests for null 
pointers/values/whatever should only be done if the value is allowed or 
expected sometimes to be null.  If it should _never_ be null -- if being 
null indicates a failure or programming error -- then either:

        (a) The test can be made to trigger WARN_ON(), or

        (b) The test can be skipped and the kernel allowed to oops.

Either of these choices will attract people's attention pretty quickly and
get the underlying problem fixed.  (b) has the advantage of requiring less
space and time along with the disadvantage of destabilizing the kernel,
making it more suitable for a development branch than a "stable" branch.

The worst possible approach is what many routines do now: test for null
and then silently fail the operation.  That way nobody will ever realize
that something's not working right.

Alan Stern




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to