On Fri, Apr 20, 2012 at 3:18 PM, Alexey Proskuryakov <[email protected]> wrote: > > I noticed a number of patches going in recently that add null checks, or > refactor the code under the premise of "eliminating potential null > dereference". What does that mean, and why are we allowing such patches to be > landed?
When there are known conditions for which a value is null that we would otherwise dereference, check first and take an alternate path in the null case. > For example, this change doesn't look nice: > <http://trac.webkit.org/changeset/114678/trunk/Source/WebCore/css/CSSStyleSelector.cpp>. > We should not try to confuse ourselves with unusual for loop forms, and > there is no explanation at all of why these changes are needed. No regression > tests either. Style aside, it is quite clear that the one of the termination conditions for the first loop is selector == null. So the second loop ought to check selector != null before any dereference of selector. Regarding style, the change homogenizes the loop constructs within that method. -- David Barr _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
