Another fun github hack: if you browse the repo for a particular file, the URL will be something like

    github.com/user/repo/blob/master/foo/bar/baz.py

But this file can change, meaning this url might not have the same content a week or month down the road. This is particularly troublesome when you have lines selected. To fix this, press `y` and your url will get expanded to include the current commit hash:

    github.com/user/repo/blob/e4ecae.../foo/bar/baz.py

Now your URL is safe to share.

You can also change "github.com" to "github1s.com" or "github.dev" if you want to view it in VSCode in browser.

i.e.

https://github.dev/torvalds/linux/blob/f4bc5bbb5fef3cf421ba3...

https://github1s.com/torvalds/linux/blob/f4bc5bbb5fef3cf421b...

Or just click on the line number to change the URL to that line.

I tried that but everything after the # got stripped when I submitted the link.

One of the first codebases I ever worked on professionally allowed gotos as part of its style guide, but only under two conditions:

1. You're using the goto for error handling and cleanup in a function; and

2. You only jump in a forward direction.

Or Knuth's take on it: https://pic.plover.com/knuth-GOTO.pdf [pdf] Structured Programming with go to Statements. Which helps to clarify why go to statements are both useful and worth minimizing, from a person who makes extensive use of goto statements in a lot of their code.

Not all gotos are made equal. A hundred gotos jumping forward to the same cleanup/error tail is very readable and actually reduces complexity over alternatives - which it’s obviously why it’s used. In many languages this type of construct has the form of try/catch/finally but those are glorified forward gotos.

Seeing even one goto jumping backward would be much more surprising, and seeing what made gotos get their bad rep, overlapping goto regions, would be completely shocking in any quality code base.

Kernels written in C are often full of gotos. There's nothing wrong with gotos per se, it's only harmful if that's your (or one of your) primary means of control flow, e.g. because you don't have other good options. BASIC for example had that problem back in the day.

Gotos can be used to effectively accomplish try/catch in C. As long as you stick to a safe goto idiom like this then they can be useful. In general, an inexperienced programmer taught that goto is okay is probably not going to stick to safe idioms and will instead create spaghetti code, hence why they are steered away.

I’ll name Linux my go-to argument in this whole debate.

Other gotos include:

- if-statements

- switch-statements

- break

- continue

- exception handling

The whole "gotos are bad" really needs to die.

Hate to break it to you, but December 1991 was 30 years ago.

It's a weird feeling where if you work on this code, it must be like living archaeology, digging up remains, but at the same time sculpting new remains for the next generation. The other profession that must be like this is Law. In some ways this file feels more permanent than the blockchain. Although someone might come refactor it to Rust one day! If you do keep the comments at least!

It's a touch nicer (IMO) if you link directly to the specific lines you're referring to, like: https://github.com/torvalds/linux/blob/f4bc5bbb5fef3cf421ba3...

"SAMMA PÅ SVENSKA" (english: "same in swedish")

In plain c, goto is about the only sane way to do error handling in an ergonomic and easily maintainable way. The only cost is the goto stigma (which is generally justified).

It's not in the codebase proper, but the Linux Test Project https://github.com/linux-test-project/ltp is probably a good place to start to see what's currently being tested for a syscall and to add new tests if there's a gap. https://github.com/linux-test-project/ltp/tree/master/testca... is some tests of this particular syscall.

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.

At first I thought you were joking, but perhaps you were serious about it?

I can't tell and I'm literally LOL right now because of that

No, it must be a joke.

> There also isn't a comment on every line

This must be a joke LOL

Why are folks downvoting?