According to Linus you’ve been brainwashed by using a garbage language https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/
> On 26 Sep 2022, at 1:43 am, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote: > > I try to be not dogmatic about GOTO statements, > in fact, I am coding COBOL in my money (everyday) job, and there are lots of > GO TOs around; > I try to remove them, when I do larger refactoring, but if not, I leave them > untouched. > > But now for another GOTO story. > > When I started my Stanford Pascal compiler adventure in 2011, the first > compiler pass (PASCAL1) > had around 50 GOTO statements in it (in fact: 50 numeric labels which are > targets of GOTOs in Pascal; > in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable; > you need a label declaration for them, not only the GOTO statement and the > target label - > because the label is local to a block, the label number may be reused in > different blocks). > The Stanford compiler, as many other Pascal compilers, is self-hosted, > that means, it is written in Stanford Pascal and compiled by itself. > The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50 > labels mentioned above > (well, this was the 1982 McGill version, to be honest). > > One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and > RETURN statements > to it (semantics like in C). It turned out that almost all GOTOs were used to > implement the missing > statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some > time) > to remove the GOTOs by replacing them by the new statements, where this was > possible > without problems. > > Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO > statemens (I just checked it). > Because, see above, I am not dogmatic about GOTO, I will leave them, as long > as there is no need > to work on the procedures containing them. > The compiler story (including downloads) is here: > http://bernd-oppolzer.de/job9.htm > > IMO, GOTOs (and the statements mentioned above) must be used with care. > If you don't use them right, nobody will be able to follow the logic in your > programs, > including yourself (after some time). Indentation is key, and meaningful > comments. > > Kind regards > > Bernd > > >> Am 25.09.2022 um 13:51 schrieb David Crayford: >> Another thing that makes me incredibly dubious about some of the opinions in >> these videos is the hackneyed nonsense about "goto considered harmful". The >> original paper was misunderstood in that all goto statements are harmful and >> brainwashed a generation. Some of these videos present a trivial example >> using goto and refactor it using if/ifelse. In programming languages without >> scope based cleanup goto is not harmful. In fact it's leads to clean code as >> the branch direction is always descending to a cleanup block. Happily for >> me, the young guys I work with writing systems level Metal/C code haven't >> been seduced by this dogmatic BS. Good C code uses goto statements as >> opposed to heavily nested or superfluously functionally decomposed routines. >> The IBM Openj9 JVM C code is a case in point >> https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. >> I challenge anybody to write better code without goto statements. >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN