Converting assembly to C

[5U4GB]

There is a nice book about this kind of adventure

There's also a book on doing it on foot, "Clear Waters Rising: A Mountain Walk Across Europe" by Nicholas Crane.  Apparently the most important thing to have with you on such a journey is an umbrella.

And for a rather more exotic one, "A Short Walk in the Hindu Kush" by Eric Newby, who didn't take an umbrella.

Now... what were we arguing about again?

[5U4GB]

For minimal bug density C code, go take a look at Dan J. Bernstein's projects.

Or Wietse Venema.  Or a couple of other people who work in the security field.  I don't know Dan's coding process but some of the others combine both very careful coding with a large amount of auditing and checking, with the result that some of their code has had essentially zero security vulnerabilities despite intensive third-party attempts to find some.  That's a pretty impressive feat when you consider other security products out there, one-person projects beating ones created by multimillion-dollar companies with vast resources.

[5U4GB]

Based on a quick grep over my test case archive, I use goto in fewer than one project in hundred.  (I didn't bother to check how often in those rare cases I use computed gotos, a GNU extension, though; it can make certain complex state machine structures much simpler to maintain without introducing new bugs.)

That's exactly where I use it, from an equally quick grep, there's a somewhat complex state machine that has to pop up from various levels of nesting and go to a common cleanup/reset section, followed by the next-state step in a while loop.  Every other way to do this without gotos, and I'd tried several, is much, much uglier and more confusing.

Maybe that'd be a good design rule, "do not use a goto unless the alternatives are much uglier and more confusing".  However that's a bit subjective, failing that the MISRA rules are generally good enough.

[tggzzz]

There is a nice book about this kind of adventure

There's also a book on doing it on foot, "Clear Waters Rising: A Mountain Walk Across Europe" by Nicholas Crane.  Apparently the most important thing to have with you on such a journey is an umbrella.

And for a rather more exotic one, "A Short Walk in the Hindu Kush" by Eric Newby, who didn't take an umbrella.

Crane also wrote about cycling in the Himalayas and has made TV programmes, Dervla Murphy left her small town for the first time - and cycled to India in the winter of '63.

I find Newby boring, but his weird chance meeting with Wilfred Thesiger is memorable. I had something similar happen on top of a 10kft mountain in the Dolomites.

All in all there are some similarities between walking across the Alps and reversing machine code into C; both are pretty pointless unless you do them "because it is there".

[5U4GB]

I think Newby wasn't necessarily boring but more oversold somewhat, it's not really the epitome of humourous Englishness or whatever.  That honour goes to Three Men in a Boat, but you have to read it in the original German.

[Langdon]

On the other hand...

Disadvantages of goto in C

I didn't ask for copy-pasted quotes from some online article.

I asked a simple and specific question - can you provide an example where goto is truly necessary and cannot be replaced with conventional structured code that avoids goto? Do you have one?

Articles are written by people like everyone else, and people make mistakes. That's why you should think for yourself instead of blindly relying on something just because someone wrote it on the internet.

This does not exist. In structured programming you can ALWAYS replace goto with other operations.

Well. I'm glad you finally admitted it.

We can only talk about where goto may be more effective than other solutions. And as you rightly pointed out, goto can probably be more effective but at the same time more insecure and error prone.

Are you serious? What makes you think that avoiding goto leads to more insecure and error-prone code?

Doesn't the example provided by the topic author clearly demonstrate that using goto results in code that even the original author struggles to understand? Do you really consider that to be more secure and less error-prone than straightforward, readable code, where the author fully understands what they are doing and which can be easily reviewed and analyzed for errors?

That's not what he? said.

He? meant that `goto` is error-prone.

Read carefully, then reply.

[radiolistener]

That's not what he? said.

He? meant that `goto` is error-prone.

Read carefully, then reply.

You're right, that was my mistake. I initially thought this should be obvious to everyone, but judging from your comment, not everyone saw it that way. Then there is a sense to clarify this.

I misinterpreted @Picuino sentence due to a combination of factors - the phrase contains a contrast ("but at the same time"), I read that part quickly, and English is not my native language. As a result, I initially thought it was saying that avoiding goto leads to more insecure and error-prone code, while in reality, it meant that goto itself is more error-prone. Thanks for the clarification. So there’s no real disagreement between me and @Picuino regarding the risks of using goto. For this reason, I’m withdrawing my question to @Picuino, as it became clear after his response.

[Picuino]

I never use the goto statement in C language. But it is not for a religious reason, actually goto is present in many C statements like break, continue or return.
I once read that goto was not as evil as one might think according to the widespread opinion in structured programming. I did some research and came across structures like the one I posted earlier that use goto for resource release.
It is true that the alternative option you posted (@radiolistener) is perfectly valid and does not use goto, but it repeats code at several points and that is also a source of errors.

Code: [Select]

void foo()
{
    if (!doA())
        goto exit;
    if (!doB())
        goto cleanupA;
    if (!doC())
        goto cleanupB;

    /* everything has succeeded */
    return;

cleanupB:
    undoB();
cleanupA:
    undoA();
exit:
    return;
}

what is the reason for goto in your example?

Here equivalent code but with no goto:

Code: [Select]

void foo() {
    if (!doA()) {
        return;
    }
    if (!doB()) {
        undoA();
        return;
    }
    if (!doC()) {
        undoB();
        undoA();
        return;
    }

    /* everything has succeeded */
    return;
}

As you can see, its much easier to read and support. And there is no need to use goto at all.

[Picuino]

Just as a curiosity. A BASIC program and their spaghetti goto structure that can generate mazes.

https://www.quora.com/Whats-wrong-with-goto-statements

[Siwastaja]

If you read old BASIC listings then it's obvious where the "goto considered harmful" mindset is coming from.

It is very rare to see anything similar in C, though. The culture of structured programming just begins from first textbook examples, tutorials and so on.

I remember as a kid writing a C program something similar to that BASIC example: it was a rudimentary chat / file transfer utility for dial-up modems, on DOS, and IIRC it was a few thousand LoC in main() with tens if not hundreds of gotos. But I was like 12 years old at the time. Such horrible practices are self-weeding; writing, reading and maintaining such mess is so horrible that anyone starts thinking, "there must be a better way". And then they discover loops, function calls and so on. I don't remember writing something like that ever again.

What I'm surprised at is that almost no one has nothing bad to say about continue and break. Yet, they do the same as goto, transfer the control flow to somewhere else bypassing loop conditions, and in some ways they are much worse than goto: with goto you have the label so there is no question where the flow goes to; with break, the flow jumps to some }, usually not the next one; sometimes the next-after-next but not always even that. To see where the flow jumps to, you scan for } forward but then for each } you look backward what the matching keyword for the block is, and only if it's for or while or do then the matching } is an effective destination for break. How convoluted.

Doing double-breaks with temporary variables multiplies that confusion. A lot of surface area of errors: you can first mis-identify the } where the first break jumps to; then you can make a mistake with how you set and compare the temporary flag; and then you can mis-identify the } where the second break jumps to. Also there is a risk of doing something in the loop body which you wanted to skip when the termination condition occurred, so you need to guard some non-related code with extra if or be careful with ordering of breaks and normal code...

Also doing a dynamic loop condition is... scary. I mean, something like, for(int i=0; i < terminated ? x : y; i++)

goto TERMINATE_LOOP;

would have solved all that with, by far, least surface area for mistakes.

But, obfuscated code is nothing new. When "goto considered harmful" cultists are delivered with arguments like in this post, they never succeed shooting them down, because the real world facts are so convincing. Instead, they change into "it is possible to write code without goto" argument. Which is hilarious. You can avoid almost any construct. The question is, at what cost? Initial claim was avoiding it makes your code better. Revised claim is that it does not make your code that much worse. Hilarious, I repeat - but cults and religions usually are hilarious to outsiders.

[Picuino]

Structured Programming with goto Statements
DONALD E. KNUTH
December 1974
https://pic.plover.com/knuth-GOTO.pdf

http://www.kohala.com/start/papers.others/knuth.dec74.html

[metertech58761]

And where was the poor OP in all this?

Staring in amazement at the TARDIS-sized can of worms he opened.

I think I'm going to take tggzzz's advice and "find another job".

[tggzzz]

And where was the poor OP in all this?

Staring in amazement at the TARDIS-sized can of worms he opened.

I think I'm going to take tggzzz's advice and "find another job".

That would be your decision based on what you can see on the ground.

As I've noted previously, Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and could get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway. I doubt he would be allowed to do that now, more's the pity.

The same is true when making a bid for a contract/sale. I've recommended "no bid" on several occasions.

Sometimes it helps to know why they are requesting reimplementation. Listen to what alternatives have been considered and rejected, and to the expected benefits of reimplementation. Work out how it will benefit their customers and why their customers will pay them more money for the same function. Sometimes marketing/sales people hallucinate a problem and/or a solution to the problem.

[radiolistener]

I never use the goto statement in C language. But it is not for a religious reason, actually goto is present in many C statements like break, continue or return.

While statements like break or if do affect control flow, they are much safer than goto. break only exits loops or switch statements, and if simply directs the flow based on conditions. Both have well-defined scopes, making them predictable and easy to follow. In contrast, goto can jump anywhere, leading to unpredictable and hard-to-maintain code. Therefore, break and if are not problematic, as they don’t allow arbitrary jumps like goto.

It’s not a matter of "religion" as some may suggest. The key difference is that goto can jump to arbitrary locations in code, making the program flow unpredictable and harder to maintain. On the other hand, statements like break, continue, and return have well-defined, limited scopes, which makes them more predictable and manageable. The concern with goto is its potential to create complex, hard-to-follow control flows, while other control statements like break and continue are structured and localized.

It is true that the alternative option you posted (@radiolistener) is perfectly valid and does not use goto, but it repeats code at several points and that is also a source of errors.

While using goto may seem like a more efficient solution by avoiding duplicated code, it actually leads to more problems in terms of code readability, maintainability, and flexibility.

In my approach, by utilizing explicit checks for resource cleanup, you can more easily manage and modify the logic for each exit path. It is true that there is some repetition, but modern compilers are capable of optimizing away this repetition, and worrying about such micro-optimizations is usually unnecessary. What is far more important is ensuring that the code remains clear, maintainable, and easy to extend in the future.

If you were to use goto, it becomes significantly more difficult to modify the cleanup logic. For instance, if you want to change the resource release behavior at a particular exit point, you'll have to create separate exit labels for each scenario (e.g., cleanupA, cleanupB, etc.). This quickly turns the code into a tangled mess, often referred to as "spaghetti code," which is much harder to read and maintain.

On the other hand, the approach without goto keeps the code linear and straightforward, with each condition clearly defined. It’s easy to change the resource release logic for any given exit condition without worrying about the structure of the entire flow.

In summary, while it might feel like goto reduces code duplication, it ultimately sacrifices readability and maintainability, which are far more important in the long run. A clean, easy-to-follow structure, even with some repetition, is a better investment for the future of your codebase.


And regarding micro-optimizations... Focusing on micro-optimizations often leads to the opposite of the intended result. By trying to manually optimize small aspects of the code, you may actually make it harder for the compiler to apply its own optimizations effectively. Compilers are highly optimized and can often generate much better, more efficient code than what developers might manually write. In many cases, attempting to optimize code at a micro level leads to slower, bulkier code because the compiler is no longer able to perform certain optimizations it would have done without the interference.

It’s generally better to focus on writing clean, maintainable code and let the compiler handle the optimizations. This approach often results in better performance and more manageable code in the long term.

[Picuino]

And where was the poor OP in all this?

Staring in amazement at the TARDIS-sized can of worms he opened.

I think I'm going to take tggzzz's advice and "find another job".

It is clear that fighting with a spaghetti code to convert it into structured C code is a real torture.
It is easier and more gratifying to throw the whole project in the trash and start another one from scratch.

[radiolistener]

I think I'm going to take tggzzz's advice and "find another job".

If you're being forced to work with such poorly structured code, it might indeed be worth considering finding a better job. However, before making any decisions, it could also be worth exploring the possibility of refactoring the code from scratch, removing the reliance on goto and creating a more maintainable structure. To do this effectively, you'll need to fully understand the code's intended functionality and flow.

Starting fresh with a clearer design can not only improve the readability and maintainability of the code but also provide a valuable learning experience. In many cases, refactoring the code will make it much easier to work with in the long run and can lead to better results both for you and the team.

[Siwastaja]

In contrast, goto can jump anywhere

Every idiot can keep repeating this like a broken record, but it does not become true. Try it. Scope of jumping with goto is pretty limited. You would know that if you either read the standard, any tutorial worth of its salt, or, simply, just tried it yourself.

You are thinking about something like setjmp/longjmp. Oh, wait, no. You are not thinking.

[Siwastaja]

It is clear that fighting with a spaghetti code to convert it into structured C code is a real torture.
It is easier and more gratifying to throw the whole project in the trash and start another one from scratch.

Possibly. However, there is some silver lining with a relatively simple, imperative language like C: refactoring and improving the structure can usually happen piece-by-piece. It's not like everything being dependent on a perfect polymorphic object model.

In other words, just start identifying repeated functionality, and make them functions. Find places where code should be data instead, and create relevant data structures, and keep going.

"Spaghetti code" (a pretty loose term but most have some kind of rough idea what it means) feels bad, but it really isn't the worst crime one can do. A project cobbled together with copy-paste code, long functions, if-else messes and, say, a lot of gotos can be saved in the same way an elephant can be eaten.

I'm much more worried when I see seriously overengineered, in CS sense, cathedrals where you have no idea how the modules interact with each other. You will just find endless meta after meta; classes with no obvious functionality related to the actual project spread over thousands of small modules.

I mean, I take a single 10000 LoC C file goto mess any day over a 10000 C++ file project, or a ProblemFactoryFactoryFactory project. At least with the spaghetti mess, you can just start following the code from the beginning of main(), and some significantly non-zero % of the code tends to do something you know the application is doing.

And don't forget the Version 2 Syndrome. It's very real and a scary risk. If v1 exists and works, and the only problem is that some software engineers feel that it's written in poor coding style, and they suggest total rewrite, be very careful in decision making. They could be right. But history shows, that 95% of such rewrites end up massively overtime and overbudget and result in a new mess which then again is "in poor coding style" according to the next engineers.

[radiolistener]

Every idiot can keep repeating this like a broken record, but it does not become true. Try it. Scope of jumping with goto is pretty limited. You would know that if you either read the standard, any tutorial worth of its salt, or, simply, just tried it yourself.

You are thinking about something like setjmp/longjmp. Oh, wait, no. You are not thinking.

Resorting to insults doesn’t strengthen your argument - it only reflects poorly on your professionalism. In fact, using aggression to assert dominance is a strong indication of a lack of experience and deep knowledge in the subject. Those who are confident in their expertise typically rely on reasoning and facts rather than personal attacks.

The concern with goto is not that it allows completely unrestricted jumps like setjmp/longjmp, but rather that it disrupts structured programming principles by allowing arbitrary jumps within a function. While the scope of goto is indeed limited to the function where it is used, it still introduces non-linear control flow, making the code harder to read, maintain, and refactor.

Structured control flow constructs (if, while, for, etc.) inherently guide the programmer toward writing more predictable and maintainable code. goto can make this harder by allowing jumps that bypass normal scoping and sequencing, increasing the risk of unintended side effects.

Even in the cases where goto is used for error handling in deeply nested logic, it still leads to more harm than good. The fact that many coding guidelines, including those for large-scale projects and even the Linux kernel, discourage excessive use of goto reinforces this point.

If you have specific counterexamples where goto leads to clearer and safer code compared to structured alternatives, I'd be genuinely interested to discuss them. Let's keep the focus on technical merit rather than personal remarks.

[Siwastaja]

I don't get it. Goto jumps to exactly where I put the label. It doesn't jump to "any" place within the function.

If you use it to jump to stupid targets, then... shame on you. You totally can use break and continue to do the same. You can wrap arbitrary pieces of code inside a loop and jump backwards (with continue) or forwards (with break) anywhere.

Seeing serious misuse of goto doesn't seem to be any more common than serious misuse of any other construct. Totally made-up problem.

In fact I would say that switch-case is a truly dangerous construct. Seen so many bugs with it. The fallthrough feature alone is much scarier than goto, which never does anything other than what is obvious from the code itself (jump to the explicit label). Still I won't call switch-case as evil and will keep using it. Switch-case is like a multi-goto on steroids, a total anti-pattern of structured programming.

[radiolistener]

I don't get it. Goto jumps to exactly where I put the label. It doesn't jump to "any" place within the function.

If you use it to jump to stupid targets, then... shame on you. You totally can use break and continue to do the same. You can wrap arbitrary pieces of code inside a loop and jump backwards (with continue) or forwards (with break) anywhere.

Seeing serious misuse of goto doesn't seem to be any more common than serious misuse of any other construct. Totally made-up problem.

In fact I would say that switch-case is a truly dangerous construct. Seen so many bugs with it. The fallthrough feature alone is much scarier than goto, which never does anything other than what is obvious from the code itself (jump to the explicit label). Still I won't call switch-case as evil and will keep using it. Switch-case is like a multi-goto on steroids, a total anti-pattern of structured programming.

The issue with goto isn’t that goto can jump to any place within a function - it’s that it allows arbitrary jumps that disrupt structured control flow.

Your argument assumes that goto always jumps exactly where the programmer intends, however, consider the original example from the topic starter - filled with bunch of labels and jumps across different parts of the functions. The goto statements do indeed jump to the exact labels placed by the author, exactly as intended. Yet, despite this, even the author of the code admitted that he don't fully understand how it works. This is precisely the problem - the goto statement may function correctly from syntax point of view, but the resulting logic becomes so tangled that even its creator struggles to follow it.

By contrast, switch-case does not suffer from this issue. It provides a structured way to branch execution, making the flow of logic transparent. Unlike goto, a switch statement explicitly maps inputs to execution paths in a way that is easy to follow. Of course, as with any construct, misuse is possible - for example, deeply nested switch statements can reduce readability. In such cases, refactoring into separate functions is a much better approach.

The key point is that structured programming constructs like if, while, and switch inherently guide developers toward more maintainable designs, while goto offers no such structure, making it far easier to create hard-to-follow code.


If you has studied graphs and understands what is tree structures, you can visualize a program's execution flow as a well-structured tree - where each branch represents a clear and predictable path of execution. This structured flow ensures maintainability, readability, and ease of analysis.

In contrast, excessive use of goto transforms this structured flow into a graph with arbitrary and chaotic connections between nodes. Instead of a predictable, hierarchical execution path, the program’s control flow becomes difficult to trace, making it significantly harder to analyze, debug, and modify. This lack of structure is precisely what leads to the well-known maintainability issues associated with goto.


The problem with goto isn’t just that it should be used rarely - it’s that it does not enforce constraints for structured control flow. This lack of constraint allows deviations from well-structured execution paths, making the code inherently fragile. Even a single goto, while seemingly harmless in isolation, introduces the possibility of uncontrolled jumps, breaking the guarantees of structured programming. As a result, any use of goto inherently degrades code quality, even if the overall structure remains visually intact and relatively easy to follow.

When working on a large project, you cannot manually verify how goto is used in every function. In a well-structured codebase, you can simply run a grep search for goto, and if no results are found, you can be confident that the control flow remains structured. However, if your search returns millions of lines containing goto, it becomes practically impossible to review every occurrence. The sheer volume makes it unfeasible to ensure that all uses of goto are safe and do not introduce unexpected or hard-to-trace execution paths.

By adding even a single goto to your code, where it may not immediately cause significant issues, you will eventually encounter a host of problems. For example, your version control system may reject your code due to the presence of goto, or your build system could fail because of it. While it’s possible to manually reconfigure the build process or request exceptions for your code with goto, this is a poor solution. In a professional environment, attempting to circumvent system constraints designed to maintain code quality in order to insert a single goto would not be accepted.

In reputable companies, every commit must adhere to established coding standards, and the build process is configured to immediately flag any potential errors or problematic code. As part of this, the code undergoes automatic analysis and inspection by parsers and code analysis tools during the build process. As a result, you won't even be able to commit code containing goto, and if you do manage to commit it, you will break the build and thereby attract the attention of the whole company.

This is exactly why even a single use of the goto statement, which doesn’t break code readability, still degrades the quality of your code and makes it shitty-code.

As you can see, this designation isn’t based on blind adherence to the idea that goto should never be used, on blind following guidelines, or for religious reasons, but rather stems from the practical challenges you will encounter when attempting to use even a single goto in your code. Even in the absence of strict rules, you will still face numerous potential issues associated with the use of goto.

[Picuino]

In contrast, goto can jump anywhere

Every idiot can keep repeating this like a broken record, but it does not become true. Try it. Scope of jumping with goto is pretty limited. You would know that if you either read the standard, any tutorial worth of its salt, or, simply, just tried it yourself.

You are thinking about something like setjmp/longjmp. Oh, wait, no. You are not thinking.

Unfortunately it is common in this forum that personal responses are written with insults, due to differences in opinions.
While it is true that in technology there may be certain “truths” or opinions that can be “proven”, it is also true that we are people and we are entitled to say what we want. There is even the right to be wrong, without that justifying in any way personal attacks.

I do not agree completely with radiolistener. I don't like goto, but I understand that it can be used in structured programming without violating its fundamental principles (as Donald E. KNUTH argued many years ago in the article I posted).
In short, we are debating opinions and everyone after reading the arguments of others is very free to follow with his own.

For my part, I reiterate my support for radiolistener to have his opinion without being attacked for it.

[SiliconWizard]

Well, it's possible that radiolistener's first posts were a bit "sententious", but I think he ended up elaborating enough to make his point.

As I said earlier, I think there's nothing particularly elegant in using "goto", even when that's efficient, because it essentially lacks structure. We use it in C (sometimes), again for lack of better constructs. So "defending" its use in general doesn't make sense; it can be defended (even though not everyone will agree) when the language in question lacks better options.

Giving the example of nested loops, some could argue that the two below do not make any difference ("pseudo-code" here):

Code: [Select]

for (...)
{
    for (...)
    {
        ...
        if (...)
            goto GetOuttaHere;
        ...
    }
}

GetOuttaHere:
    ....

and

Code: [Select]

OuterLoop: for (...)
{
    InnerLoop: for (...)
    {
        ...
        if (...)
            exit OuterLoop;
        ...
    }
}
...

But there's a fundamental difference in terms of code structure. The second is more compact and much less error-prone. No amount of inserting code at the wrong place or moving a label could make it fail, and the intent is also easier to catch and analyze. It doesn't exist in C and C++, but it does in Ada. And I think I've heard it's coming for C.

Heck, some could even argue, taking this further, that the following is a perfectly valid and equivalent way of doing a for loop, and that for/while constructs are merely sugar-coating for this:

Code: [Select]

initialization;
MyForLoop:
    if (condition)
    {
        body...
        post statement;
        goto MyForLoop;
    }

Thus failing to see the merits of structuring code flow with easy-to-analyze constructs.
Of course, that's the extreme, although I can guarantee you that quite a few people won't see a single difference.

But again, most reasonable uses of goto in C are for breaking out of nested loops and avoiding duplicated code in error handling.
For the former, future revisions of C should solve that, as I mentioned. For the latter, it's doubtful.
And then, if you work in an environment with strict coding guidelines that forbid the use of 'goto', then problem solved: you don't have a choice. If you don't like it, change jobs.

[metertech58761]

One other thing. Just because I currently had a statement that shall not be named in my code, doesn't mean that I could have eventually come to understand C well enough to possibly, maybe, perhaps, eventually remove said highly offensive statement from the code???

Having people come in and stomp all over me with a pair of spiked boots certainly is conducive to learning, hm??

[Nominal Animal]

There is even the right to be wrong, without that justifying in any way personal attacks.

Absolutely not.  Logical fallacies like arguments from authority are anti-science, anti-engineering, and need to be burned with fire and scorn in technical discussions.  They are no better than using religion as a basis for technical and scientific decisions, and must be scorned, or we will fail.

Rules for primarily social interaction differ from those for technical discussions.

In a technical discussion, we do not pose opposing opinions.  That is what social people do.  It does not work for technology or science, because reality is not a social construct.  Instead, we discuss the reasons behind those opinions.  The opinions themselves are worthless; in fact, they have negative worth, unless the reasons behind those opinions are discussed, because only those reasons and experience can be compared.  Opinions themselves are simply the current conclusion, and if stated in the "this is my opinion, take it what you will" manner, simply clutter a technical discussion without bringing anything that could be rationally and logically examined into it.

To simplify, opinions in isolation are worth shit, and deserve no respect.  They are simply the conclusion, the wrapping paper around the thing itself.

I and others have described why specific uses of goto are warranted, in an effort to prove that a blanket statement like "using goto makes your code inferior and shitty" is simply provably incorrect; that it should be reserved for the very few cases where its use is better than any alternatives, but those few cases do exist.  To generalise, no rule of thumb covers the entire domain, only a small subset of it.

Countering that by an argument from authority –– essentially, "I'm an expert, trust me bro", or "You think you know better than X?" –– is idiotic.  It is what most humans do in social situations, yes, but in a technical discussion it is ridiculous and shows that the person is not interested in discussing the reasoning and logic behind their current understanding and opinions, and is instead engaging in social games like "saving face" and "looking for admiration" and "one-upmanship".

The only way to stop that that seems to work, is to insult the person who engages in that, in the hopes that they will reflect on it (some time in the future, perhaps weeks or months later), and adjust their output and interaction with other technical people.  Ignoring such behaviour will only mislead others into believing there might be merit in that.  All that is required for nontechnical bullshit to prevail is for rational logical people to ignore it.

(I'm sure that if I had better social skills, I could point that behaviour out in some sarcastic manner that is effective but is not personally insulting.)

Me saying "radiolistener is full of shit" is a colloquial expression intended exactly in that sense.  I am not at all interested in online social dances and games; I am interested in problem solving, discussing understanding and experience (leading to various opinions), and helping others learn.

If you find this attitude or approach distasteful/unwanted/negative, take it up with Dave and the moderators.  (I mean this at its face value: it is something you should try to discuss with them, if you have any kind of logical reasons for believing so.  If you simply believe so or take that as an axiomatic truth, or expect technical people to respect even illogical and provably untrue opinions, do be ready to be laughed at.)

Please, do not try to passive-aggressively hint or indicate that it is somehow inferior/unwanted/negative in the hopes of changing others' behaviour: that is social, and this is a technical forum.  Not everyone has the social sensibilities you do: what you think and believe is natural and professional conduct, is pure social nonsense to others, and vice versa.  The only thing we can really rely on, as shown by the past few centuries, is rational and logical thought, the scientific method, and engineering.  As social animals, humans are easily misled using interaction tricks like logical fallacies and appealing to social hierarchies and popularity; those never lead to good technical or scientific outcomes.  I know you believe in the wisdom of the herd and that popularity correlates with technical quality, but in science and engineering, those beliefs have been proven incorrect time and time again.