Harald Nordgren <haraldnordgren@xxxxxxxxx> writes: >> It is not too big a deal, but I find that liberal sprinkling of >> UNLEAK() is somewhat unsightly. From the code we leave with this >> change, it is clear what we'd need to do when we make the code fully >> leak-proof (i.e. we'd have a several lines to free resources held by >> these two variables here, and then UNLEAK() that appear earlier in >> the function will become a "goto cleanup;" after setting appropriate >> value to "status"), so let's not worry about it. > > Removed the "extra" unleak annotations within the if-return blocks, > but kept them at the end. I actually think that is worse. The UNLEAK()s near early-return serve to remind us: "here we are making early return and when we properly plug the leak, here is one of the places we need to fix". Please keep them, unless (and I do not recommend to do this) you are plugging the leaks for real.
