The use of goto out (or similar) is idiomatic in a lot of kernel code. Since C has no notion of defer (like Go) or a finally block (like languages with exceptions), you place the code you want to always execute at the end, and then goto out instead of returning earlier.
The other option, in functions like this, is to have duplicated "deferred" execution scattered throughout the function at each return point. This is a maintenance nightmare as it can be hard to discern which code is actually part of the "deferred" block (and needs to be copied) and which isn't, at least at a glance. So differences in two return points are clues that something may be wrong, but requires further investigation to determine if they should or should not be the same. As a function grows in size, this becomes increasingly problematic.
goto usage in systems programming is actually much more prevalent and less of an anti-pattern/smell than in other contexts. This is because you often need to ensure every resource acquired during the function is cleaned up along each branch that the function could exit through. Because in systems programming you'll often do an operation, check if it succeeded and exit if not. The goto resource cleanup pattern avoids you having to duplicate the clean-up-partially-acquired-resouces at every early-return statement.
Looking through that file, I didn't see a single goto (but I could have missed one) that didn't go to one of: unlock_out, out, or error. I don't think there would be any diminishment of runtime efficiency if you dropped the goto statements, and it may actually improve performance to drop them since they correspond to a jump that could be removed from each of their occurrences. Though it would also increase the code size (everything in that section of code has to be replicated), so that could be an issue. Tradeoffs, would have to be measured to know for sure.
However, they do improve the maintainability of the code. I find it interesting, looking at them and having done a quick reread of Knuth's take on goto statements (for another comment I made here) that these uses correspond to what other languages possess as syntactic elements in the structured programming vein, which is one of the things he discusses in favor of both structured programming and goto statements. In favor of structured programming, you get new syntactic elements that provide useful semantics that make the code clearer. Why are we doing this jump? Oh, it's a conditional (if/then/else) or a loop (for, while). But when you lack the syntax and semantics for that, the goto statement can fill in the gaps (when used carefully, deliberately).
Specifically, out mostly corresponds to defer (in Go) or finally in other languages. error is like try/catch/finally in Java and others. unlock_out would be like the with statements you get in some other languages.
EDIT: Reexamined this specific source file. Most of the out sections are 0-2 statements in addition to the return. So in the 0 case, there ought to be a performance improvement by just returning, though I imagine a compiler can optimize the goto's away. In the 1-2 statement range it'd be a tossup on whether the increase in function size would cost more (cache miss and similar) than the indirection itself costs. I only saw one (it's a large file, I didn't look too closely) that had a larger out section than 2 statements, and that one had enough that the indirection is probably worth the performance cost.
But, in all cases (except the 0-statement case) it still is better from a maintainability perspective, whether or not it helps performance. In the 0-statement case, I wonder if they're vestigial. If there were other statements included that were dropped for some reason. But I'm not going to dig further into this because now it's time for me to study.
There also isn't a comment on every line, no test coverage that I can see, many functions are longer than 20 lines, and many of these source files are way too big at thousands of lines.
Probably easier to throw the whole thing out and start again.
> Without a winking smiley or other blatant display of humor, it is utterly impossible to parody a Creationist in such a way that someone won't mistake for the genuine article.
(the original phrasing)
But it works for other things as well. When a position is known to be, or believed to be, accepted by a significant number of people, and someone expresses that position, without knowing them it's impossible to tell if it's sarcastic or sincere. Even if it's presented in a somewhat exaggerated form, there are people would still hold some of the views the GP expresses.
> there are people would still hold some of the views the GP expresses.
"People"? Try 100% of (good) CS professors. Research clearly dictates that gotos are harmful. Lack of comments is just as bad. As for the test coverage, that's just their loss. I'm sure this "linux" project would have much higher velocity (agile term, look it up) if they used test driven development.
The other option, in functions like this, is to have duplicated "deferred" execution scattered throughout the function at each return point. This is a maintenance nightmare as it can be hard to discern which code is actually part of the "deferred" block (and needs to be copied) and which isn't, at least at a glance. So differences in two return points are clues that something may be wrong, but requires further investigation to determine if they should or should not be the same. As a function grows in size, this becomes increasingly problematic.
It's actually a good demonstration of DRY.