> > 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.
Hi Alan, if you check out the patch you will see that I concluded that all the tests in question fell into case (2) and removed them. I think we both agree about case (2). I guess there is some confusion about case (1). If the result of not testing is that the driver oopses (and maybe can't be used anymore), but the core is left in an OK state then that is case (2) and not case (1). Case (1) is when the core will, for example, get into an inconsistent state if the check is omitted. In that case testing is necessary. If the test fails, a BUG may be quite appropriate. Remember, I was arguing against Dave's code bloat argument, and pointing out when tests should not be removed (and maybe improved). Ciao, Duncan. ------------------------------------------------------- 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
