This is a subtle thing but my preference on this type of thing is the
way the original code is written. I'm still slightly annoyed that
someone once made me rewrite a patch using the new style... But anyways
I guess other people sometimes disagree with me.
Unwinding is for when you allocate five things in a row. You have
to undo four if the last allocation fails. But say you have to take a
lock part way through and drop it before the end of the function. The
lock/unlock is not part of the list of five resources that you want the
function to take so it doesn't belong in the unwind code.
If you add the lock/unlock to the unwind code, then it makes things a
bit tricky because then you have to do funny things like:
free_four:
free(four);
goto free_three: <-- little bunny hop
unlock: <-- less useful label
unlock();
free_three:
free_three();
free_two:
free(two);
free_one:
free(one);
return ret;
It's better to just do the unlocking before the goto. That way the
lock and unlock are close together.
if (!four) {
unlock();
ret = -EFAIL;
goto free_three;
}
Of course, having a big unlock label makes sense if you take a lock at
the start of the function and need to drop it at the end. But in this
case we are taking a lock then dropping it, and taking the next, then
dropping it and so on. It's a different situation.
regards,
dan carpenter
--
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
