There have been a bunch of major security vulnerabilities due to mistakes involving GOTO in C, being used as suggested by the article. Here’s a memorable one: https://www.imperialviolet.org/2014/02/22/applebug.html
if considered harmful
GOTOphobia considered harmful in C
21–30 of 319 posts
Re: GOTOphobia considered harmful in C
#22> Bad code is the product of bad programmers This person is living in a pretend bubble that isn't grounded in the reality of large projects, multiple team members, deadlines, changing requirements, etc. No programmer is perfect. And when your tool can cut your arm off, you should be careful or route around the dangerous bits when possible.
This analogy implies that all other tools are 1000% safer, but they are not. In C it’s like pointing to a dusty corner behind a table in a room full of dirt.
When was the last time you did “cut your arm” with goto specifically? What’s the count and time ratio to other issues? Were these also addressed as taboo or left as “experience earned”? Gotophobia in its largest part is just a stupid meme with no real world data.
Re: GOTOphobia considered harmful in C
#23There have been a bunch of major security vulnerabilities due to mistakes involving GOTO in C, being used as suggested by the article. Here’s a memorable one: https://www.imperialviolet.org/2014/02/22/applebug.html
I’d say this was more due to the case not being properly enclosed in brackets. Many people seem to really dislike using the brackets but this is what that gets you.
This is detected by -Wmisleading-indentation now.
Re: GOTOphobia considered harmful in C
#24In RAII languages[0], you obviously don't need unrestricted gotos. However, I always find myself missing it when writing nested loops. Labeled break and continue[1] ought to be considered standard structure programming primitives. These are restricted gotos and allowing them to break or continue a parent loop doesn't unrestrict them much. But it does significantly improve the expressive power of your looping construc…
Go doesn't have RAII or destructors, it has defer.
Re: GOTOphobia considered harmful in C
#25goto can be replaced by a function call for cleanup.
Re: GOTOphobia considered harmful in C
#26> On the other hand, today we have the very opposite situation: programmers not using goto when it's appropriate and abusing other constructs, what ironically makes code only less readable.
One I see all the time from beginners is creating a finite state machine using one method per state and jumping between states by calling the next state’s method from within the current state’s method. Essentially just emulating goto with the added disadvantage that you’re pushing each new state onto the stack until it overflows, so refactoring it using goto would constitute an improvement.
The fact that beginners reinvent this pattern over and over demonstrates it’s easier for people unfamiliar with programming to reason about a program that uses goto, which would explain why it was so ubiquitous in the early days of computing and given its shallower learning curve its usefulness as a teaching aid as a first step before structured programming is being overlooked.
Re: GOTOphobia considered harmful in C
#27There have been a bunch of major security vulnerabilities due to mistakes involving GOTO in C, being used as suggested by the article. Here’s a memorable one: https://www.imperialviolet.org/2014/02/22/applebug.html
That error is not due to goto, it was just a goto which was errously executed because of badly formatted code. (It looked like the statement was inside an if-block due to the indent.)
Pyhon would have prevented this bug, but so would a formatter. Rust also requires braces for if-blocks to prevent this kind of error.
Re: GOTOphobia considered harmful in C
#28goto can be replaced by a function call for cleanup.
I’m curious what you are calling that can cleanup local variables and temporaries?
Re: GOTOphobia considered harmful in C
#29The C version:
int* foo(int bar) {
int* return_value = NULL;
if (!do_something(bar))
goto error_1;
if (!init_stuff(bar))
goto error_2;
if (!prepare_stuff(bar))
goto error_3;
return_value = do_the_thing(bar);
error_3: cleanup_3();
error_2: cleanup_2();
error_1: cleanup_1();
return return_value;
}
int* foo(int bar) {
scope(exit) cleanup1();
if (!do_something(bar))
return null;
scope(exit) cleanup2();
if (!init_stuff(bar))
return null;
scope(exit) cleanup3();
return do_the_thing(bar);
}
Re: GOTOphobia considered harmful in C
#30It’s interesting to think that when I wrote DVIView (TeX DVI previewer running on VM/CMS) in Pascal/Web in 1987, I found goto to be an absolute necessity (although part of that was doubtless because the relevant logic was closely modeled on Knuth’s DVItype which also used goto. I would have a hard time coming up with the last time that I needed a goto since then (or, for that matter, labeled break/continue).