Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GOTOphobia considered harmful in C

blog.joren.ga

Post reply on HN
Print view View original

281–290 of 319 posts

Re: GOTOphobia considered harmful in C

#281

Post by pjmlp »

raldi wrote: post #274
pjmlp wrote: post #250

Earlier quoted context omitted.

Arduino uses C++, thankfully.

Everything in the top-level comment applies to C++, too.

My "thankfully" remark shows my point of view.

The only sin of C++ is the same that plagues evolutionary languages like Typescript, Kotlin and so forth.

No matter how many tools they provide to write better code than the language they have grown from, their compatibility with them is like hearding cats while trying to have everyone adopt best practices.

Otherwise in regards to Arduino, I would suggest a couple of nice BASIC and Pascal compilers like those sold by Mikroe.

Re: GOTOphobia considered harmful in C

#282

Post by pjmlp »

deckard1 wrote: post #167
eric__cartman wrote: post #147

Earlier quoted context omitted.

The ATmega 328P an Arduino Uno or Nano uses has 2KB of memory and 32KB of flash storage for the program. Having some sort of micropython interpreter there would be impossible, and even if it could be achieved, somone still has to write the low level C/ASM code to make it all work. For many embedded systems, low level languages like C or C++ (perhaps Rust for a lot of ARM micros) is the only sensible choice. If it's n…

> has to write the low level C/ASM code to make it all work shhh. Let's not disturb those that believe in the GC fairy that sprinkles their code with safety magic late at night while they soundly sleep. Firmware doesn't exist. I can't hear you. Na na na na na na na

Too late, here is Firmware being written in Go.

https://www.withsecure.com/us-en/solutions/innovative-securi...

Re: GOTOphobia considered harmful in C

#283

Post by dcow »

pjmlp wrote: post #267
jstimpfle wrote: post #265

Earlier quoted context omitted.

I don't see any similarity between gotos and signals at all. Gotos are just explicit jumps, while the "normal" structured way of doing jumps is to have them inferred from nested regions (that double as scopes and lifetime guards for automatic variables). The structuredness of such inferred jumps usually is both sufficient and convenient, but sometimes being extremely structured leads to boilerplate and inefficiencies…

Signals are implicit GOTOs in the sense of INTERCAL's COMEFROM. As for structured handling, instead of gotos all over the place, do inverted conditions for early returns similar to what Swift has done with guard statement, embrace functions for resource cleanup, if the cost of a jump brings cold sweat, have them inline and called alongside a return, most compilers will replace calls with jmp opcodes.

You clearly don’t understand the problem. Imagine all the ifs properly inverted like you want them to be. Good. Now imagine you have to free 6 allocations, close 3 FDs, and wait on a few threads before returning. Imagine you have 10 early returns. Your cleanup function would be an unreadably silly 10 arg thing with extra pointers everywhere and you have to call it 10 times. Thats insane boilerplate just because you cant stomach a local goto. Why not just goto cleanup, avoid the mess, save a bunch of time, and cleanup naturally and locally in the same function where everything is defined?

Re: GOTOphobia considered harmful in C

#285

Post by bazoom42 »

randomdata wrote: post #280
bazoom42 wrote: post #276

Earlier quoted context omitted.

Dijkstra is not just arguing all exits should return to the same point, but also that you shouldn’t enter or exit in the middle of a block. Execution should consist of executing blocks zero or more times, but either fully or not at all. Exiting in the middle of a block would be just as bad as entering in the middle, according to the argument he is making.

You certainly wouldn't be the first to hold that view. However, Dijkstra accepts abortion clauses, which is what return really is (it is not an exit clause). My take is that his argument is that an unbridled go to is too primitive and that he believed go to statements should be bridled by additional structure that help describe the process, not that go to should be avoided entirely. While I think we can agree that re…

> You certainly wouldn't be the first to hold that view.

It is not my view. I happen to disagree with Dijkstra on that point.

Re: GOTOphobia considered harmful in C

#286

Post by randomdata »

bazoom42 wrote: post #285
randomdata wrote: post #280

Earlier quoted context omitted.

You certainly wouldn't be the first to hold that view. However, Dijkstra accepts abortion clauses, which is what return really is (it is not an exit clause). My take is that his argument is that an unbridled go to is too primitive and that he believed go to statements should be bridled by additional structure that help describe the process, not that go to should be avoided entirely. While I think we can agree that re…

> You certainly wouldn't be the first to hold that view. It is not my view. I happen to disagree with Dijkstra on that point.

View of what Dijkstra said. How one feels about the subject has no meaning nor relevance to the discussion.

Re: GOTOphobia considered harmful in C

#287

Post by PaulHoule »

arp242 wrote: post #77
ufo wrote: post #50

I always encourage people to go read Dijkstra's GOTO paper, instead of just its title. It's a short and easy read, almost like a blog post. If you pay attention, you can see that the he was talking about spaghetti code vs structured code. It's better when the lexical structure of the source code maps to the execution structure. That is, if you know what is the current line being executed, you have a good idea of what…

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years. It easy to misunderstand what he was even talking about becau…

BASIC?

GOSUB was so much worse than GOTO in that it had a stack for the current line but no stack for variables so you could not write recursive functions. I think Fibonacci as a recursive function is malpractice but boy was it a hassle to write Quicksort in BASIC although I had no trouble coding up an FFT (1950s FORTRAN style) from first principles in BASIC on TRS-80 Model 100 on a bus ride across Vermont.

Funny though I did come to a conclusion that for the Arduino programs I wrote I didn’t need a stack at all.

Re: GOTOphobia considered harmful in C

#288

Post by RustyRussell »

nullc wrote: post #227
strangattractor wrote: post #113

Earlier quoted context omitted.

If you have ever seen someone try an construct a bunch of nested IF statements with complicated conditional clauses you might think GOTO is not so bad. People have simply become better coders. There are also still GOTOs that are used in specific cases such as CONTINUE and BREAK - no labels required. If I look back it always comes back to naming and managing names of things. GOTO 100 is meaningless and one eventually…

A better rule than goto harmful is gotos should only go lower in the function and should only exit blocks and/or skip over them, never be used to enter them.

Generally true, but I've been known to do `goto again;` for those cases where retrying is a corner case. Sure, you can put the entire code inside a `for(;;)` but if it almost always only runs once, you're not helping the reader understand the code.

Re: GOTOphobia considered harmful in C

#289

Post by ziml77 »

_kst_ wrote: post #220
mort96 wrote: post #140

Earlier quoted context omitted.

To give people some kind of an idea of what it was created in response to: Imagine writing an entire program in one single main function. The only thing you're allowed to do for flow control is goto. You can do 'goto somelabel;' for an unconditional goto, or you can do 'if (somecondition) goto somelabel;' for a conditional goto. Here's some examples of how it would look if if translated to something C-like: Loops wou…

Could be worse. https://github.com/Keith-S-Thompson/fizzbuzz-c/blob/master/f... #include #include int main(void) { jmp_buf jb[7]; volatile int j = 0; setjmp(jb[0]); volatile int i = 1; if (j == 0) setjmp(jb[1]); if (j == 1 && i > 100) longjmp(jb[6], 0); if (j == 1 && i % 15 == 0) longjmp(jb[4], 0); if (j == 1 && i % 3 == 0) longjmp(jb[2], 0); if (j == 1 && i % 5 == 0) longjmp(jb[3], 0); if (j == 1) printf("%d\n", i);…

I am sobbing in pain at that atrocity.

Re: GOTOphobia considered harmful in C

#290

Post by maldev »

benj111 wrote: post #110
maldev wrote: post #73

Earlier quoted context omitted.

Yes. There's a reason pretty much every secure C coding standard dictates exact what I said, like CERT C etc. There's a reason they have weird bugs. Just because it's an impressive piece of software, doesn't mean it can't have horrible design pattern written by substandard coders. And in an open source project with as many contributors as Linux, I would say it's not hard to fathom that there's a significant number of…

or maybe its that things like a kernel reasonably need to use goto? or at least at the time it was written, there werent alternatives that were performant enough.

I'm not saying not to use goto. The above example works on any C language, with some tweaks needed to K&R. I've done substantial Kernel work and can tell you that there's no reason to ever break my example and put multiple goto stubs. Can you provide a single situation where it is needed and there's no other alternative? I can't prove the negative you want me to.
Post reply on HN