The notorious goto statement (12)

1 Name: Nameless : 2025/10/11 22:27

Are you man enough to use it?

2 Name: Nameless : 2025/10/12 01:47

A "Shit Happens" bumper sticker. A good go to statement.

3 Name: Nameless : 2025/10/12 02:20

"Takes one to know one."

4 Name: Nameless : 2025/10/13 14:22

I get the problem with goto, but also for exception handling in C? It's really nice.

5 Name: Nameless : 2025/10/18 12:29

I remember fucking around with gwbasic a few months ago for fun and goddamn, I am glad we live in a time where goto is gone. Writing any program of any length is ass due to mucking about with subroutines.

>>4 is right though, as a fast exit from problems, goto is useful there. Probably the one good reason it should be in C.

6 Name: Nameless : 2025/12/19 07:08

I used goto when I had to show a readable version of the code for a dummy

7 Name: Nameless : 2025/12/21 18:15

I use it for state machines, but you haven't really seen all structured programming can do, if you don't regularly write loops with the condition at the end or somewhere in the middle. Even for 90% of "exceptions" you can easily factor cleanup into a subprogram and write a familiar if cascade.

8 Name: Nameless : 2025/12/29 08:15

i wish python had it

9 Name: Nameless : 2025/12/30 11:31

>>7
Okay, yes, you can. However, the standard calling convention dumps extra shit into the stack, which is what I'm trying to avoid. A goto statement is much smaller overall.

10 Name: Nameless : 2025/12/31 07:06

>>9
The compiler should be able to correctly decide when to inline, but you can always use the pragma or write a macro regardless. Inside a short function writing an equivalent loop is just as convenient more often than not, even if i agree to goto being cleaner in some cases.

11 Name: Nameless : 2026/01/01 08:38

>>10
I don't compile with optimization to get better at making optimizations myself BEFORE the compiler gets a chance to clean up my fuckups, so I just assume the compiler isn't working for me at all times despite the compiler being smarter at times.
Anyways, since we're kind of on this subject anyways, how would you recommend approaching try {} catch {} (finally {}) on a low level language like C, which is function based?

12 Name: Nameless : 2026/01/03 19:42

>>11
Step one:
Devise a function prototype for your subprogram and decide whether to return something and/or pass something by reference. Some return types, like pointers or non-zero integers, can be abused to signal an error. Otherwise you should return a non-zero integer on error.
Step two:
Depending on your function layout, either return early on error or return early on success.
Step three:
React to the error in your program context.
Example:
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>

int parse_int(char *p, size_t n, int *result) {
size_t i;
int j;

for (i = j = 0; i != n; i++) {
if (p[i] < '0' || p[i] > '9')
return 1;
j = j*10 + p[i] - '0';
}

*result = j;
return 0;
}

int main(int argc, char **argv) {
int fd, i;

for (i = 1; i != argc; i++) {
if (parse_int(argv[i], strlen(argv[i]), &fd)) {
write(1, "Usage: poke fd ...\n", 19);
exit(100);
}
if (write(fd, "", 1) < 0)
dprintf(1, "%s: %s\n", argv[i], strerror(errno));
}
}
Name: E-Mail:
Leave these fields empty (spam trap):