Are you an idiot or just play one or TV?
Posted Jul 23, 2009 5:35 UTC (Thu) by khim
In reply to: Fun with NULL pointers, part 2
Parent article: Fun with NULL pointers, part 2
It's not even funny: you are discussing one particular function in
it's current incarnation where Eric discusses the whole
Adding the null pointer check does not cause the first bug you
mention, although it may help to reveal it.
But it can crash the perfectly working system tomorrow after some kind
The second item is a coding style issue, not a bug (and your
logic is circular; you try to show that adding the BUG_ON is a bad idea, so
you cannot assume that in your argument).
Today human mistakes are promoted to "code style issue"? News to
The third assertion needs some evidence, and even if true
cannot be used to show that adding any particular line of code introduces a
There were a lot of investigations. Number of bugs per line of code does
not change too much when you switch languages, paradigms, etc. It reduces
if you do a lot of rafactoring (like kernel developers do) and srinks when
you are using different autodetection tools (which are they using too),
this change is pretty limited. It'll be somewhat strange to see that BUG_ON
is somehow 100 times less buggy then the rest of the code.
any more than you could use it to justify removing one
particular line of code from the middle of your program.
Yup. Justification is the same as for the rest of code: if you function
will continue to work - why have this line in first place? Redundant
comments can be kept around, but actual line of code? Please - a lot of
stuff kernel developers are doing is this exact "removal lines of code from
the middle of your program".
(It is sometimes the case that adding overzealous error
checking introduces a bug, but that needs to be shown in each individual
case, and you haven't shown it here.)
And now sound almost adequately. If sometimes overzealous error checking
introduces a bug then it's good idea to keep it out of program:
asserts, coverity, etc. These things can detect bug but they can not
introduce new bug (false positive is not a bug as it's not compiled in
Defensive programming makes sense when you suspect other code has lower
quality (userspace, drivers for obscure devices, etc), but to try to
protect code from code of equal quality with so-called "defensive
programming" is to increase number of bugs!
to post comments)