Ah, that's a classic approach: no clue, but strong opinions. "goto" hardly qualifies as a sign of bad code; otherwise the Linux kernel would be in a terrible position. If used well, it's a valid solution to many flow-problems.
I know goto is not necessarily a sign of bad code and there are situations where they are needed. That being said even though I am not the most experienced, I have never needed to use a goto (except QuickBasic maybe).
The linux kernel works very well but does "just working" necessarily mean that that is the only way have it function. "It works" doesn't mean its good code.
I did not look at the code very closely but one goto I saw seemed to point from the main loop into a function. Which to me seems like an odd use, a use that can easily be avoided.
That's because you have not yet programmed enough / read enough programs.
> I did not look at the code very closely but one goto I saw seemed to point from the main loop into a function. Which to me seems like an odd use, a use that can easily be avoided.
Goto from one function to another? Not possible in standard C. If this was written in C it is most probable that compiler optimisation caused the direct jump. Even if you were not indeed talking of something like that you missed the obvious that compilation optimisation and imperfection of the decompilator are the far more probable cause of presence of curious goto.
You could also have noticed the far more interesting use of cast of char* to function pointer which are then called. Did the original programmer wrote this mess? Hint: probably not too...
As for the quality of the source code of the Linux kernel, well, apart from if you work on safety critical software (in which case it's like comparing apples to carrots anyway, because they are far more important differences to general purpose software than the mere presence or absence of gotos) I doubt you've seen a lot of far better code.
Indeed I even doubt you could advance reasonable reason for why goto should be 100% banished in all situation, especially when doing dynamic allocation or resources. Maybe you don't even have ever read the original Dijsktra's paper or the Knuth's paper http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pd... (curiously (or not) it's the case for many cargo cult goto haters even for just the orinal Dijkstra's paper)
I'm a little surprised that nobody has pointed out this is a decompiled version of the code. That means it took machine language and tried to convert it back to C. Given that machine language only has goto in it, anywhere where you might see a loop in this code is from the decompiler looking at a stereotypical usage of the jump instructions and reverse engineering a C loop statement.
At the base level, programs are nothing but gotos strung together. Everything else is added at a higher layer.
Also, critiquing the coding style of decompiled output is particularly missing the point. But at least the brace style is consistent, right? Almost as if it were rigidly generated by a tool from another source of input, rather than by a human, no?
Seriously, it is one of the biggest open-source C codebases out there, with thousands of hackers working on it. And the result is very good, as the majority of the internet is running on it.
I don't argue that linux itself is bad, it's obviously very good overall. That doesn't say anything about overall code quality though - as usual there are good, bad and really ugly parts.
"I've looked at the source and there are pieces that are good and pieces that are not. A whole bunch of random people have contributed to this source, and the quality varies drastically." -Ken Thompson
