On Sun, Feb 8, 2015 at 4:55 AM, SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx> wrote: >> Your proposed patch (while technically correct) hurts code clarity. > > How many source code readability and understanding challenges does each > additional condition check cause? Please don't make a mountain out of a mole hill in an attempt to defend your robotic patch (I'm quite tired of some of these static analyzer patch submissions). FYI, I did stage your other patch for 3.20, see: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-for-3.20&id=d0ce7e911c97c7c6df1081dcedfefced82a0c6bf > Can the affected place become also a bit more efficient? Efficiency isn't a concern in this instance (it isn't a hot IO path). And even if it were, a branch (with current code) is more efficient vs a a jump + branch (your proposed patch) -- in the case that no active table exists. Now if it likely that old_map does exist then yes your patch is always a very slight win. But given the duality of the calling function (deals with loading a new map and destroying the old map if it exists) I prefer to keep the code as is. Sorry. -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
