On Sat, 2023-12-30 at 08:04 +0100, Markus Elfring wrote: > > > The kfree() function was called in up to three cases by > > > the ses_enclosure_data_process() function during error handling > > > even if the passed variable contained a null pointer. > > > This issue was detected by using the Coccinelle software. > > > > Why is this an issue? The whole point of having kfree(NULL) be a > > nop > > Such “a nop” can trigger the allocation of extra data processing > resources, can't it? No. > > is so we don't have to special case the free path. > > A bit more development attention can hopefully connect the mentioned > label with a more appropriate jump target directly. That's making the flow more complex as I pointed out in my initial email. > > The reason we > > do that is because multiple special case paths through code leads > > to more complex control flows and more potential bugs. > > You probably know some advices from another information source. > > https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources > Yes, but it's about using staged deallocation at the end of the function instead of in the if loops. That's to *simplify* the exit chain and make the error legs less error prone because the teardown isn't repeated in if bodies. It has no bearing on what you just tried to do. > > If coccinelle > > suddenly thinks this is a problem, it's coccinelle that needs > > fixing. > > This software tool can help to point source code places out for > further considerations. The search patterns are evolving accordingly. The pattern is wrong because kfree(NULL) exists as a teardown simplification. James
