Goto bad Spooktober tale: Counting goto in the Linux kernel

[magic]

This guy always sounds like somebody bringing home wheelbarrows of gold thanks to his advanced knowledge of safety critical software development on obsolete hardware

Very happy with his job, no doubt.

[Siwastaja]

I have absolutely nothing against him, although many of his ideas I find pretty weird, but weird in a good way; I don't prefer to sit in an echo chamber. I also disagree with some ideas such as hiding pointer-ness behind a type and naming convention instead of using language built-in syntax to convey that information, but ultimately such things are also matter of taste, and if he finds hiding pointerness and not using gotos help him writing safer code, what can I say? It doesn't work for me but probably works for others. I don't understand the personal attack on projects. Me working on building automation systems doesn't mean I'm not allowed to even discuss safety critical software any more than himself having worked on embroidery machine control project.

[Nominal Animal]

Pointing out that the Linux kernel uses goto is like pointing at someone using a leg prosthesis, and shouting Ha ha! Look at that stupid peg leg!


Me, I don't trust standards and regulations, not even ISO or POSIX C or MISRA-C or DO-178B.  I highly appreciate the principles and the reasoning behind them, and try to abide by those –– especially security, robustness, reliability, and maintainability –– depending on my needs, but practice trumps theory.  Always.

Arguments like this one, especially when they get personal, make me go .

Some of you argue based on DO-178B, the others do freestanding/hosted development under review-based quality control.  They're not the same environment!
Define your own context, basis of argument and environment, before getting caught up in the argument.  Yes, it leads to over-long posts like mine, but at least then you have a chance of arguing about the same thing, instead of a similar thing in wildly different contexts.  Apples and pineapples.

One related case that I recently thought about is the fact that in ISO C, binary right shift of negative values is implementation defined.  This means that a particular C compiler could choose to "optimize" code by having any right shift of a negative value do nothing.  If anyone complains, they can simply point to the standard and point out – correctly – that they're fully compliant already.
Me, I am only interested in compilers that generate an arithmetic right shift on negative two's complement integers, i.e. (-29) >> 1 == -15.  Generating anything else is just silly and anti-useful on the architectures I use, from 8-bit AVRs to 64-bit AMD64/x86-64 and ARM64.
Thus, my code is not strictly portable in the ISO C standard sense.  Yet, in practice, my code tends to be quite portable, with just a set of notes and restrictions one can test.

This means that if anyone asks me if >> on an intN_t or int_fastN_t-type expression is safe in C, my answer depends on the context (but I often assume one, rightly or wrongly, based on the names/labels the asker used).  Or I explain the standard stance and my attitude towards it.
Similarly, I need to see a particular case of goto use (including the project context), to even have an opinion about it.

To have an opinion about goto use in the Linux kernel, without showing superior C constructs that yield the same or better machine code on all architectures, is just shouting "Ha-ha!".  Not useful, not informative; just juvenile.

[DiTBho]

This guy always sounds like somebody bringing home wheelbarrows of gold thanks to his advanced knowledge of safety critical software development on obsolete hardware

This is another one of those things that annoys me, but note that almost none of my colleagues ever talk about what they do for work, each of us has spent ~50K euro and 10 years on training, in open source you don't find any of this, and yet, instead of appreciating, you do nothing but making fun of my category, when the concept that "we would be" trained "monkeys" who "follow orders" is even conveyed.

Sorry, I really don't think I will ever say anything else in this forum.

[ejeffrey]

Basically goto is like the C preprocessor.  It's a low level construct that can be very powerful, but also can cause a lot of problems.

I don't think it's quite fair to say "they can be abused just like any other language construct" I think fundamentally both of them should be considered as dangerous to use and best to be avoided, but there are a lot of particular use cases that cover shortcomings of the language that are better implemented with those features that without.  If I were to design a C/C++ like language, I would be happy to include both, but would strive to make sure that the core language covered as many known use cases as possible so that nobody wanted or needed to use them.

Error handling is the most common case in C where goto is often really the best solution.  But C++ has RAII which generally covers most if not all of those cases.  As a bonus, it can do so more efficiently -- goto error approaches often require tests for each possible resource to be cleaned up since you don't know where you jumped in from, while RAII automatically invokes exactly the required cleanup handlers.  Usually a trivial difference, but might make sense in some situations.

Exiting a nested for loop is another common use of goto.  It's a bit more controversial since there is an often superior alternative which is to factor the loop into a function and use return, but it's still a core feature that C doesn't have: targeted break/continue. 

If C had clean support for registering function level cleanup expressions and targeted break/continue, probably 99% of uses of goto would go away.  And that doesn't mean the other 1% are bad uses, but there would be a lot fewer to consider on a 1-off basis.

The preprocessor is the same way.  Very old compilers didn't support inlining well, so macros were used for optimization, even though it had problems with parse confusion and side effects.  Now compilers are good at inlining and that use is now pretty much obsolete.  C doesn't support polymorphic functions, so macros can be (carefully) used for that purpose -- although C11 introduced generic functions that are better to use when they work.  C doesn't allow even constant variables to be used for initialization, so preprocessor macros have to be used for that.  The list goes on.  Even "standard use case" is something that should be considered for making a dedicated language feature. 

So people categorically labeling these structures as bad without caveat ignores the fact that they are being used as real solutions for shortcomings of the language.  Suggestions they be replaced with more complex code to achieve some abstract purity are not helpful.

And of course, the cure isn't always better than the disease.  C++ templates let you do a lot of powerful generic programming that would otherwise be done by the preprocessor, and do so in a type safe manner, but abuse of the template system can be as bad as the preprocessor macros it replaces.

[DiTBho]

but practice trumps theory.  Alway

That's precisely why I mentioned the Windriver's approach!

It's not that I was describing something on a theoretical level, I made precisely the practical discussion, because someone cited the linux kernel to argue that "gotos are fine", and I pointed out that it would be better to look at WxWorks, simply because if there is no documentation on linux (and frankly I often struggle to understand what exactly the code does in case of error propagation), everything is documented on WxWorks!

I then mentioned DO178B to underline that the Windriver's approach is a kind of simplified subset, which is good even when you are part of a small team and you have to deal with a lot of work(1) to do and with many things to verify. Thanks to Windriver, you have a simplified rule-set where "goto" are allowed for error-handling and have documentation (mandatory), which help to understand how to manage the test-reports!

Again, it's not something on a personal level, otherwise I would have told you that in my-c language *any goto* is always forbidden, and here I would have started to mention how I have already solved the whole "goto thing" on both theoretical and experimental levels.


(1) which is mandatorily required by the life cycle watertight compartmentalization procedures described by these regulations.

[Nominal Animal]

It's not that I was describing something on a theoretical level, I made precisely the practical discussion, because someone cited the linux kernel to argue that "gotos are fine", and I pointed out that it would be better to look at WxWorks, simply because if there is no documentation on linux (and frankly I often struggle to understand what exactly the code does in case of error propagation), everything is documented on WxWorks!

No, actually you didn't.  Reread your first two posts, reply #2 and reply #3.  You'll understand how the discussion derailed.  Reply #3 was, intended or not, just yelling "Ha-ha! Look at that peg leg!"

If you had instead constructed a reply along the lines you intended, say

The error propagation patterns where goto is used in Linux are not well documented, or specified in any style or design guide I can find, and I do have difficulty unraveling them.  Thus, I don't think that goto are fine just because they're used in the Linux kernel, at all.

In my opinion, it would be much better to look at e.g. WindRiver WxWorks sources and documentation for error propagation patterns: they do it right.

and then maybe add a bit about your experiences/opinion working on both, and what this means when one gets paid to work under MISRA-C or DO-178B rules, the thread would have continued very, very differently.

I know that's very much along the lines of what you intended (we've discussed similar details and Linux kernel wonkiness elsewhere); it just came out wrong.  All this mess is just a communications issue, worth fixing, but not something to get irritated over.

I like you and Siwastaja both; I sometimes agree, sometimes disagree with both of you.  I like to argue with you both (and SiliconWizard and RoGeorge and others; I like you too!), as we keep it to things and don't usually let it go personal.  When it does, it needs to be fixed, because otherwise many useful and interesting future arguments will be lost, not-had at all.

In this particular case, I chose to step in (and in this way), because I know you know I myself struggle a LOT with communication, and we've discussed elsewhere about the approaches that work better, and our own typical failure patterns.  Simply put, I can see myself doing exactly the same error here, and I'd like the error to be fixed, so we can go back to arguing about the interesting stuff instead.  Tough love, if you like.

Perhaps I should have done this via PM instead, but didn't because DiTBho didn't start the thread, and my was more directed at RoGeorge for starting the thread in the first place and everyone else equally for arguing, well, about the statistics of goto use!
Thus, I suppose I too failed in my communication attempt here.  I apologise. 

[nctnico]

goto is a normal part of C and trying to avoid using it for political reasons leads to less readable spaghetti code.

You can just as easely argue using goto leads to unreadable code due to jumping to other parts of a function which makes it hard to follow a function (and where it actually exits). But the same can be argued about using return somewhere in the middle of a function and break and continue in for/while loops. I'd say using a goto is typically an indication of problems getting the code structured in a way that the code is easy to follow.

In the Linux kernel using goto is typically done for an on-exception-exit pattern. Most of the drivers use gotos in their init section where depending on how far the process gets, dynamically allocated memory gets unallocated in case the driver initialisation fails. IMHO this is one of the very few good uses of goto in the C language: crude exceptions.

[Siwastaja]

You can just as easely argue using goto leads to unreadable code due to jumping to other parts of a function which makes it hard to follow a function

Quite obviously, but I chose not to reiterate that viewpoint because it seems to be very very very commonly known and discussed already. (The very reason why people do stuff like grep goto on linux kernel.)

The two typical uses for goto in C are as you mention exception handling during initializations, which I demonstrated above with code, and in some cases, for breaking out of a 2D loop without having to resort to unintuitive temporary variables.

And no, 2D loops are not evil per se. For example, if you process a 2D image then x and y loops make perfect sense and it would be confusing to refactor into a function call (loop_row() or what?) just to get rid of one level. And C doesn't have named loops and break only breaks one level, so goto fixes both: it adds labels and allows breaking two levels.

Now one could argue that most if nearly all good uses of goto always jump forward, but I'm sure someone can come up with a good example where jumping backwards is better than the alternatives, but this would be a rarity. Personally I have done that when handling exceptional error cases where I just want to "start over" instead of "giving up", as a quick fix for the edge case instead of spending a lot of time figuring out how to refactor the whole thing so that this edge case handles "more elegantly".

We were taught in university how goto is bad because you can jump anywhere, including other functions but that obviously was a lie and tells a lot about the level of understanding in the academic world.

[nctnico]

I wouldn't call it a lie but rather an over-simplified model. I'm from the period when universities started teaching Pascal in order to make students think about structuring their software in an elegant way. Quite usefull until the point some people start to have the crazy idea you can write real software in Pascal 

[DC1MC]

...
We were taught in university how goto is bad because you can jump anywhere, including other functions but that obviously was a lie and tells a lot about the level of understanding in the academic world.

Why no one is discussing animore about  setjmp and longjmp in C 

Cheers,
DC1MC

[DiTBho]

You'll understand how the discussion derailed.  Reply #3 was, intended or not, just yelling "Ha-ha! Look at that peg leg!"

Can you see how frustrating this forum is?

I said in order

• Linux is not a good reference. Is it? you confirmed it's not
• then I mentioned PPC because it's what I am working at the moment and it's happening right now that we have 5 months of regression, Linus himself is complaining
• so, Linux is not a good reference, not even for looking at how gotos are used
• at that point someone suggested that a big problem is documentation, and I confirmed it
• little anecdote about how the "cowboy to the console" approach to the wild west of Linux, can even create absurd situations where if nobody understands absolutely nothing about the code then it's a big problem for development. It was full of gotos, in many point it was abused, strange pointer arithmetic, inline assembly and all kinds of shenanigans, and to understand how the code worked, thousands of hours of work were needed, practically rewriting everything from scratch
• then I pointed out that if there are no precise regulations you end up having little projects that only stand up if there are a lot of people following them, just like Linux, or worse still, just like linux in my anecdote
• at that point I suggested looking elsewhere, pointing out that where there are regulations, things are much better both understandable and manageable, even by small teams
• I mentioned VxWorks, and the discussion derailed *HERE* when I pointed out Windiriver's approach, and note why it derailed: because some "troll" willfully misunderstood what I wrote in order to ridicule those who do competent work

And frankly it bothers me a lot that people who don't even have the competence to speak (for example about DO178, someone here called it "bullshit for trained monkeys"), and this is because they have never done anything mission critical, often allow themselves to start a reply with the "it's bullshit", as happened in the topic of cyclomatic complexity.

Even worse when what they call "bullshit" often has serious reasons behind it, sometimes reasons of an organizational and not just technical nature.

And this because "practice" means "organize people doing software" as important as "design software" as well as "find a resonable way to allocate resources to test software".

All points that have continued to be repeated for years, and you explain it and every damn time we always come back to the same points, over and over, which makes me realize that arguing in this forum is a total waste of my time.


So, sorry, but no.

[Siwastaja]

Or, maybe you just take someone calling a practice "bullshit" (A) personally, (B) too seriously? I mean, it's not that strong of a word. It just means whoever said that does not believe the practice is good at all. More important is to look why they think the practice is bullshit. And don't get hurt on behalf of a process.

I don't remember seeing that "trained monkey" thing you refer to, and it's nasty language I admit that. I have never ever name-called professionals working on the regulated fields you mention, and have no reason to do that. If you read what I wrote, you will see it's the opposite; I'm happy I can create software more freely and still sleep well, not being on their shoes; and I'm happy I can still discuss what I think about safety critical software, but it seems you are not happy about me discussing it.

But whatever. I think your fundamental issue on this forum is in anger management and poor communication. You are not the only one, I can say from personal experience of having the exact same issue. But in reality, others are not as stupid as you may think. Give us a chance.

[DiTBho]

But in reality, others are not as stupid as you may think. Give us a chance.

... well, about that, it's you who that, misunderstanding what I wrote, thought that we must be really *very stupid to accept*(1) - according to your interpretation -  that it is enough to make Chatgpt(1) write some random documentation in the code to pass a piece of code by the QA team, who is composed by professionists!

I didn't specify what it was "necessary condition, not sufficient", my fault there, I edited my post, but how many times have I repeated how things really work? How many? So, before starting with "I'm horrified", didn't you even have any doubts? no, because in your opinion we only do bullshit! It takes you very little to brand things as "bullshit" (like in the Cyclomatic topic, where I simply ignored some of your bad statements), and it costs me too much time to explain it to you, and then what? See, you didn't even get the concept!

Damn, this is the common pattern here in this forum(2), and it's really frustrating!

Among other things, if I have always underlined that developers and testers should never talk to each other except through specific documents, the Windriver's approach creates a shortcut that allows, through mandatory documentation, to better describe both the code and the various doubts about how to write and test it, which is brilliant "extension" because it reduces the numer of iteractions and helps people growing up "team building"!

It seems like something within everyone's reach, because everyone can start describing the code, obviously in a concise and targeted way; Windriver pays some professionists with skills in being concise and targeted way, and QA guys have the same skill, so here OpenSource guys have to learn to do it well, but it's a true benefit and it's feasible, if not mandatory, it should at least become a habit!


(1) precisely here I saw the offense to the entire category

[Siwastaja]

I merely commented on your claim that AI cannot be used to cheat "because it's in natural language". Don't take it out of context. I totally agree with what you now write; that competency in management is what prevents such cheating. You(!!) are the one who mentioned cheating with AI, as if it would happen if the document were not in natural language! You were the one whose descriptions about these regulated fields made me horrified. You are the one giving bad picture about "your" field. You fail to communicate because you are arrogant and write quicker than you think when angry.

And while I trust a lot of safety critical software (otherwise, I would not board an airplane), I still have my doubts about how the arrogance you show affects your work.

Now can you do us all a favor and start actually ignoring people you claim to ignore and therefore stop derailing threads? Thank you in advance.

[thm_w]

Code: [Select]

int do_thing()
{
    turn_relay_on();
    if(!good_to_go)
    {
        turn_relay_off();
        return FAILURE_1;
    }

    if(asdf != 123)
    {
        turn_relay_off();
        return FAILURE_2;
    }

    do_rest_of_stuff();
    turn_relay_off();
    return SUCCESS;
}


You can write it this way instead:

Code: [Select]

int do_thing()
{
    turn_relay_on();
    if(!good_to_go)
        result = FAILURE_1;

    else if(asdf != 123)
        result = FAILURE_2;

   else
    {
    do_rest_of_stuff();
    result = SUCCESS;
    }

    turn_relay_off();
    return result;

Anything that relies on copy pasting required steps in multiple locations is generally bad code. Regardless of having goto's or not.

[cfbsoftware]

Damn, this is the common pattern here in this forum(2), and it's really frustrating!

I believe it would help let off steam in this forum if we could just mark a message as "Say No Thanks" instead of "Say Thanks" and then move on.

[SiliconWizard]

Damn, this is the common pattern here in this forum(2), and it's really frustrating!

I believe it would help let off steam in this forum if we could just mark a message as "Say No Thanks" instead of "Say Thanks" and then move on.

That's not a bad idea indeed.

[Siwastaja]

That idea has been discussed before and while on surface it looks like a good idea, it quickly becomes stack overflow / reddit type "downvote into oblivion" system. "Thank you" thing might be unnecessary, but at least it's mostly positive (even that is used in a nasty way, "thanking" some users from very low-quality contributions just because they disagreed with someone with "wrong" opinion, but that use pattern is at least complex and thus not too common, compared to direct downvoting).

Users already have a way "to move on". Everyone posts here at their free will. Being able to be negative against people in a yet another (and easier!) way only results in more negativity, not "moving on".

[metertech58761]

When I started learning C++, I too was told "GOTO bad. VERY BAD. Here your dunce cap. Stand in corner!"

After stewing on that a while, I came up with a different take; I write the code as I please, then go back and say "How many GOTO can I take out and still understand what's going on?"

[Karel]

In the poll, I'm missing the option: Linus and his lieutenants know what they are doing