Linux

8394 readers

237 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of [email protected] and The GIMP

founded 2 years ago

MODERATORS

[email protected]

An (almost) catastrophic OpenZFS bug and the humans that made it (and Rust is here too) (despairlabs.com)

submitted 1 day ago by [email protected] to c/[email protected]

10 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 23 points 1 day ago* (last edited 1 day ago) (2 children)

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:

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.

[–] [email protected] 11 points 1 day ago (1 children)

But what would that help in this situation? You could as easily write result = asize; and the psize would again be unused.

[–] [email protected] 10 points 1 day ago* (last edited 1 day ago)

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 int result = -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.