This one could be helped by always using this pattern whenever you write a function that returns a value, in any language, along with no early returns:
int func(...) {
int result = -1;
...
return result;
}
I always start with writing my result default value, ideally indicating failure, and the return line. Then I implement the rest. We often don’t have the luxury of choosing the language we work with that has the features we like, but consistently enforced code style can help with a lot of problems. Anyone can make mistakes like the one in this bug regardless of experience so every little bit helps.
You could absolutely do that and be fucked too. However the point of the pattern I suggested isn’t to replace the return with an assignment. That is, the point isn’t to do the exact same implementation and then do result = something before returning it. Instead it’s to use the initialized result var to directly store your result throughout the function, at every place where you manipulate it. So in this case my suggestion is to not have psize at all. Instead start with intresult=-1; and return result; and do all the things you do to psize except on result. Then there’s a higher chance you will return the right value. Not a guarantee. I’m not at all implying that “if they only did this one thing, they wouldn’t have fucked up like this, so stupid” I’m merely suggesting a style that can decrease the probability of this type of error, in my experience. I’m teaching my team to write in defensive ways so they can feel some confidence in what they wrote, even if they slept 2 hours the night before, and also understand it after another bad night. Cause that ends up happening, life happens and like OpenZFS we also can’t afford serious bugs in what we do.
Scary indeed.
This one could be helped by always using this pattern whenever you write a function that returns a value, in any language, along with no early returns:
I always start with writing my result default value, ideally indicating failure, and the return line. Then I implement the rest. We often don’t have the luxury of choosing the language we work with that has the features we like, but consistently enforced code style can help with a lot of problems. Anyone can make mistakes like the one in this bug regardless of experience so every little bit helps.
But what would that help in this situation? You could as easily write
result = asize;and thepsizewould again be unused.You could absolutely do that and be fucked too. However the point of the pattern I suggested isn’t to replace the return with an assignment. That is, the point isn’t to do the exact same implementation and then do
result = somethingbefore returning it. Instead it’s to use the initializedresultvar to directly store your result throughout the function, at every place where you manipulate it. So in this case my suggestion is to not havepsizeat all. Instead start withint result = -1;andreturn result;and do all the things you do topsizeexcept onresult. Then there’s a higher chance you will return the right value. Not a guarantee. I’m not at all implying that “if they only did this one thing, they wouldn’t have fucked up like this, so stupid” I’m merely suggesting a style that can decrease the probability of this type of error, in my experience. I’m teaching my team to write in defensive ways so they can feel some confidence in what they wrote, even if they slept 2 hours the night before, and also understand it after another bad night. Cause that ends up happening, life happens and like OpenZFS we also can’t afford serious bugs in what we do.