News for hackers. Stuff that matters.
Re:Banned C standard library functions in Git source code by alister on Sunday August 25, 2019 @10:43AM (#20793257)
I'm glad to see that setjmp() and longjmp() are still allowed.

I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling.

More info: https://en.wikipedia.org/wiki/Setjmp.h

Re:Banned C standard library functions in Git source code by LukeShu on Sunday August 25, 2019 @11:02AM (#20793360)
The way I see the list is that it isn't meant to be exhaustive, it's meant to be functions that contributors are likely to try to use. A new contributor might not realize that they should be using Git's internal strbuf.h instead of the libc string functions. It's a way to give them feedback on that from their compiler, before they spend more time on the patch and send it to the mailing list.
Re:Banned C standard library functions in Git source code by masklinn on Monday August 26, 2019 @03:33AM (#20798063)
Also seems mostly for functions which look innocent and are likely to be used but are very easy to misuse.

setjmp/longjmp is not in this category, it might be argued to be easy to misuse but doesn't look innocent and is not likely to be used in normal codebases.

Re:Banned C standard library functions in Git source code by rkagerer on Sunday August 25, 2019 @03:33PM (#20794986)
Might be nice if the error messages suggested such alternatives instead of just saying "banned"?
Re:Banned C standard library functions in Git source code by grogenaut on Sunday August 25, 2019 @05:53PM (#20795841)
I believe the git project welcomes suggestions and discussion via the mailing list, and also accepts patches that like you suggested above.
Re:Banned C standard library functions in Git source code by Lerc on Sunday August 25, 2019 @04:09PM (#20795225)
I had quite some fun playing around with it to obfuscate code. I did find that jumping to a different position in the same expression broke on a lot of compilers as soon as optimization was turned on.

Here's a simple program to output a string with the characters in an unusual order.

    #include <stdio.h>
    #include <setjmp.h>

    #define J(x,y) (longjmp(x,y),0)

    int main(int argc, char **argv)
    {
        jmp_buf j[011];
        int x,X=0;
        signed char* i = " eehcef lo u ef'oYurls " +021;

        (x=setjmp(j[X++]))?J(j[x],*++i):((x=setjmp(j[X++]))?J(x[j],*--i):((x=
        setjmp(j[X++]))?J(x[j],(putchar(*i),*i+=128)):(x=setjmp(j[++X]))?((x<
        0)?J(1[j],5):J(2[j],3)):(x=setjmp(j[++X]))?((x>>X)?J(1[j],6):J(1[j],3
        )):(x=setjmp(j[++X]))?((x&0x80)?J(1[j],7):J(1[j],5)):(x=setjmp(j[++X]
        ))?(((X<<5)&x)?J(1[j],4):J(2[j],X)):(x=setjmp(j[++X]))?((x&128)?J(0[j
        ],X):J(2[j],4)):(setjmp(j[3])>=0)?J(j[2],6):0));

        return 0;
    }
Re:Banned C standard library functions in Git source code by begriffs on Sunday August 25, 2019 @05:04PM (#20795580)
> the same expression broke on a lot of compilers as soon as optimization was turned on

C is not a "try it and see" language. If you stray from the spec then things will act differently and break between compilers. Section 7.13.2 specifies that only local variables declared as volatile will have a determinate value after a longjmp.

Re:Banned C standard library functions in Git source code by kazinator on Sunday August 25, 2019 @04:13PM (#20795255)
ISO C says that any local variables that are not declared volatile whose values are mutated after the context is saved with setjmp then have indeterminate values when the context is restored with longjmp. So yes, that interacts with optimization. Any variable that is cached in a register may revert to its old value when that register is restored blindly from jmp_buf.
Re:Banned C standard library functions in Git source code by mcherm on Sunday August 25, 2019 @05:10PM (#20795616)
You, sir, have a crafty and evil mind. Well done.
Re:Banned C standard library functions in Git source code by valleyer on Monday August 26, 2019 @01:35AM (#20797660)
This was super fun to decipher!

1. The first time through this giant ternary defines 9 different small subroutines. Each subroutine can consider the value of "x" to be their argument. X is used as an index into the jmp_buf (subroutine) array during setup, but after that it's always just equal to 8

2. Subroutines 0, 1, and 2 are special. Their argument is the index of another subroutine to jump to. They mutate the character buffer state and then jump to the specified subroutine

3. Before jumping, subroutine 0 moves back a character, subroutine 1 moves forward a character, and subroutine 2 prints the current character and marks it by setting its high bit. Once a character is marked, it will never be printed again

4. All other subroutines get the current character value as their argument

5. Subroutines 3, 4, 5, 6, 7, and 8 all check, in different ways, whether the current character has been marked: x < 0, x >> 8, x & 0x80, (8 << 5) & x, x & 128, x > 0

6. Execution starts at subroutine 3

So you can annotate the code as:

    // Subroutine 0:
    //   move to next char;
    //   goto x;
    (x=setjmp(j[X++])) ? 
     J(j[x], *++i) :
    
    // Subroutine 1:
    //   move to prev char;
    //   goto x;
    ((x=setjmp(j[X++])) ? 
     J(x[j], *--i) :
    
    // Subroutine 2:
    //   print and mark (set high bit on) curr char;
    //   goto x;
    ((x=setjmp(j[X++])) ?
        J(x[j], (putchar(*i), *i+=128)) :
    
     // Subroutine 4:
     //   if (curr char is marked) {
     //     // goto 1(5);
     //     move to prev char;
     //     goto 5;
     //   } else {
     //     print and mark curr char;
     //     goto 3;
     //   }
     (x=setjmp(j[++X])) ?
        ((x<0) ? J(1[j],5) : J(2[j],3)) :
     
     // Subroutine 5:
     //   if (curr char is marked) {
     //     // goto 1(6);
     //     move to prev char;
     //     goto 6;
     //   } else {
     //     // goto 1(3);
     //     move to prev char;
     //     goto 3;
     //   }
     (x=setjmp(j[++X])) ?
        ((x >> X) ? J(1[j], 6) : J(1[j], 3)) :
     
     // Subroutine 6:
     //   if (curr char is marked) {
     //     // goto 1(7);
     //     move to prev char;
     //     goto 7;
     //   } else {
     //     // goto 1(5);
     //     move to prev char;
     //     goto 5;
     //   }
     (x=setjmp(j[++X])) ?
        ((x & 0x80) ? J(1[j], 7) : J(1[j], 5)) :
     
     // Subroutine 7:
     //   if (curr char is marked) {
     //     // goto 1(4);
     //     move to prev char;
     //     goto 4;
     //   } else {
     //     print and mark curr char;
     //     goto 8;
     //   }
     (x=setjmp(j[++X])) ?
        (((X << 5) & x) ? J(1[j], 4) : J(2[j], X)) :
     
     // Subroutine 8:
     //   if (curr char is marked) {
     //     // goto 0(8);
     //     move to next char;
     //     goto 8;
     //   } else {
     //     print and mark curr char;
     //     goto 4;
     //   }
     (x=setjmp(j[++X])) ?
        ((x & 128) ? J(0[j], X) : J(2[j], 4)) :
     
     // Subroutine 3:
     //   if (curr char is not marked) {
     //     print and mark curr char;
     //     goto 6;
     //   } else {
     //     exit;
     //   }
     (setjmp(j[3])>=0) ?
        J(j[2],6) : 0));
    
    // X = 8
    // goto 3(0);
A more straightforward way of writing this would be

    #define IS_CURR_CHAR_MARKED() (*i < 0)
    #define PRINT_AND_MARK_CURR_CHAR() do { putchar(*i); *i += 128; } while (0)
    int curr_sub = 3;
    
    for (;;) {
        switch (curr_sub) {
            case 3:
                if (!IS_CURR_CHAR_MARKED()) {
                    PRINT_AND_MARK_CURR_CHAR();
                    curr_sub = 6;
                } else {
                    return 0;
                }
                break;
            case 4:
                if (IS_CURR_CHAR_MARKED()) {
                    i--;
                    curr_sub = 5;
                } else {
                    PRINT_AND_MARK_CURR_CHAR();
                    curr_sub = 3;
                }
                break;
            case 5:
                if (IS_CURR_CHAR_MARKED()) {
                    i--;
                    curr_sub = 6;
                } else {
                    i--;
                    curr_sub = 3;
                }
                break;
            case 6:
                if (IS_CURR_CHAR_MARKED()) {
                    i--;
                    curr_sub = 7;
                } else {
                    i--;
                    curr_sub = 5;
                }
                break;
            case 7:
                if (IS_CURR_CHAR_MARKED()) {
                    i--;
                    curr_sub = 4;
                } else {
                    PRINT_AND_MARK_CURR_CHAR();
                    curr_sub = 8;
                }
                break;
            case 8:
                if (IS_CURR_CHAR_MARKED()) {
                    i++;
                    curr_sub = 8;
                } else {
                    PRINT_AND_MARK_CURR_CHAR();
                    curr_sub = 4;
                }
                break;
        }
    }
Re:Banned C standard library functions in Git source code by Lerc on Tuesday August 27, 2019 @03:43AM (#20807146)
That's quite impressive work. It becomes a bit clearer if you think of the string as a tape. Then a big case statement with Left,Right,Mark seems rather Turing complete :-)
Re:Banned C standard library functions in Git source code by begriffs on Sunday August 25, 2019 @04:51PM (#20795490)
> you can jump anywhere, not limited to the same function

Outside of the current function, yes. Anywhere, no.

Longjmp allows you to return to places you’ve already been and have saved with setjmp. Also attempting to longjmp to a function that has since returned is undefined behavior. Thus longjmp’s usual use case is like exceptions in other languages, going back up the call chain, skipping intermediate functions.

Re:Banned C standard library functions in Git source code by ryandrake on Sunday August 25, 2019 @11:19AM (#20793434)
I think reasonable people can debate this one. setjmp()/longjmp() are very useful when working with libpng [1] and jpeglib [2], as you mentioned, as a crude exception handling mechanism. I have seen these functions used in production safely for that purpose. I can imagine other horrible uses for them though. Unlike things like strcpy() which are security-holes-by-design, setjmp()/longjmp() should be in a "carefully code review the exact way these are used" list rather than a banned list.

1: http://www.libpng.org/pub/png/libpng.html 2: https://www.ijg.org

Re:Banned C standard library functions in Git source code by slovenlyrobot on Sunday August 25, 2019 @11:37AM (#20793529)
The trouble is how they compose with the expectations of code you don't write. It's just not normal in C to expect execution of your function to abort halfway through, and so memory leaks and broken state are almost guaranteed when they're mixed with the wrong third party library.

It might work great when you wrote it, but it might not even survive the next change to the codebase, and 10 years out, who is to know what programmers will come along and plug new stuff in without noticing the stack magic, etc

edit: another aspect of the same issue is that it can be difficult or impossible to write generic longjmp-safe code for many kinds of tasks. In C++ you have stack unwinding to e.g. delete large temporary heap allocations during a complex operation, but no such facility exists in C.

Re:Banned C standard library functions in Git source code by megous on Sunday August 25, 2019 @12:28PM (#20793822)
longjmp will not interrupt third party code (well maybe if it uses callbacks and you use it from a callback).

setjmp/longjmp will almost certainly require tracking any resource use carefully so that resources can be released at the setjmp point, when execution gets back there.

I mostly use it for terminating the recursive descent parsing on error. Otherwise it gets tedious to check return values everywhere in hand written code.

Re:Banned C standard library functions in Git source code by smcameron on Sunday August 25, 2019 @09:52PM (#20796908)
> very useful when working with libpng

There is no reason libpng needed to use setjmp as part of its API, and that it does so is (I hope) widely regarded as a bad decision. It's "useful" only in so much as that is the API it defines, but there is no reason that this had to be the case, and simply returning an error code would have been very very much preferable.

Re:Banned C standard library functions in Git source code by caspper69 on Monday August 26, 2019 @07:07AM (#20798805)
Didn't glibc use setjmp()/longjmp() for task switching eons ago (maybe even pre-Linux)?
Re:Banned C standard library functions in Git source code by slovenlyrobot on Sunday August 25, 2019 @11:14AM (#20793413)
These are used /everywhere/ in PostgreSQL, exactly for exception handling. The result isn't bad at all, but indeed, too powerful a tool for 99% of developers
Re:Banned C standard library functions in Git source code by CamperBob2 on Sunday August 25, 2019 @04:13PM (#20795258)
Fortunately, 99% of developers, like 99% of drivers, are better than average.
Re:Banned C standard library functions in Git source code by cmroanirgo on Sunday August 25, 2019 @06:39PM (#20796081)
> 99% ... are better than average.

I'm thinking there's a flaw in your mathematics...

Re:Banned C standard library functions in Git source code by elgenie on Sunday August 25, 2019 @07:04PM (#20796218)
99% of the people on Earth have a higher than average number of legs.
Re:Banned C standard library functions in Git source code by saalweachter on Monday August 26, 2019 @09:56AM (#20799882)
And a below-average number of heads.
Re:Banned C standard library functions in Git source code by mrbungie on Sunday August 25, 2019 @06:47PM (#20796122)
No flaw with math/stats here, that can actually happen. I think you're confusing average/mean with median (50-percentile).

PS: I'm not sure where he's getting his numbers though

Re:Banned C standard library functions in Git source code by sooheon on Sunday August 25, 2019 @07:04PM (#20796214)
I'm 99% sure that was tongue in cheek.
Re:Banned C standard library functions in Git source code by jraph on Sunday August 25, 2019 @09:36PM (#20796868)
I think that it would have been even funnier to say that 99% of developers and 99% of drivers are better than the median, but I only figured this thanks to your parent's comment.
Re:Banned C standard library functions in Git source code by aiCeivi9 on Monday August 26, 2019 @10:41AM (#20800249)
https://insights.stackoverflow.com/survey/2019#evaluating-co...

> 70% of respondents say they are above average

Re:Banned C standard library functions in Git source code by dragonwriter on Monday August 26, 2019 @12:30PM (#20801163)
Depends which average it refers to any of the means, or the media, or the mode can be “average” (most typically, though, it means the arithmetic mean), and it's only impossible in terms of the median.
Re:Banned C standard library functions in Git source code by LorenPechtel on Monday August 26, 2019 @01:00PM (#20801516)
Exactly. Anything where you have a main clump with a long tail will show this pattern--most samples will be better than the mean.
Re:Banned C standard library functions in Git source code by Stratoscope on Sunday August 25, 2019 @10:58PM (#20797137)
You've never been on a project that was 80% done and 80% to go?
Re:Banned C standard library functions in Git source code by ConceptJunkie on Monday August 26, 2019 @12:19PM (#20801067)
And after the second 80% is finished, then you only have 80% left.
Re:Banned C standard library functions in Git source code by Merg on Monday August 26, 2019 @04:31AM (#20798229)
Not native speaker here, but I think, he just meant that, most programmers and drivers thinks they are better in respective things then, they really are.

It is just like letting programmer build a house. It is just a really bad idea.

Re:Banned C standard library functions in Git source code by fanf2 on Sunday August 25, 2019 @04:08PM (#20795219)
And Lua’s exceptions are somewhat odd because they are based on setjmp/longjmp. https://www.lua.org/manual/5.3/manual.html#4.6
Re:Banned C standard library functions in Git source code by masklinn on Monday August 26, 2019 @03:34AM (#20798066)
Apparently they're also used for error handling in libpng. That's one of the reasons the libspng author started on their project.
Re:Banned C standard library functions in Git source code by crankylinuxuser on Sunday August 25, 2019 @11:49AM (#20793578)
And that's the perfect usage for goto. Error catching and jump to fail block...
Re:Banned C standard library functions in Git source code by johannes1234321 on Sunday August 25, 2019 @01:26PM (#20794181)
Goto requires the fail block to be in the same frame. It can be a working error strategy for failing critical errors in such a way from a failing module. You have to be aware that lots of stuff is prone to leak (which can be avoided by i.e. using some memory arena) and locks/mutexes/... might be in unclear state, so code has to be aware of that.
Re:Banned C standard library functions in Git source code by userbinator on Sunday August 25, 2019 @01:57PM (#20794410)
The destination of the goto is usually the clean-up code.
Re:Banned C standard library functions in Git source code by johannes1234321 on Sunday August 25, 2019 @06:46PM (#20796116)
That's nice for the single frame.

Let's take the example of PostgreSQL, which was mentioned in this thread: A potential implementation (I have no knowledge of pgsql internals) might be that for a single user session all memory is from a single arena, all locks and other handles are tied to the session handle, then it can be an efficient strategy to longjmp out on a critical error (i.e. IO error) and clean the arena as well as things tied to the session. instead of bubbling this up through all frames.

Re:Banned C standard library functions in Git source code by Mikhail_Edoshin on Monday August 26, 2019 @02:46AM (#20797919)
It's a different use case. There was a nice article[1] about exceptions in plain C with setjmp and longjmp.

[1] http://www.on-time.com/ddj0011.htm

Re:Banned C standard library functions in Git source code by IshKebab on Sunday August 25, 2019 @01:27PM (#20794192)
You're in the 1% though right?

Funny way of saying "too error-prone for anyone sane to consider using".

Re:Banned C standard library functions in Git source code by kijiki on Sunday August 25, 2019 @10:20PM (#20796995)
It is also the only way for an xlib program to survive losing its connection to the X server. xlib will let you register a callback to handle loss of connection with XSetIOErrorHandler, but unconditionally calls exit() after your callback returns. Which is extremely anti-social behavior for a library, but that is what it does.

So the solution is to setjmp before each call to an X function that might notice the connection is closed, and longjmp out of the error callback. Ugly, but it works.

These days, you should really just use XCB, or even Wayland.

Re:Banned C standard library functions in Git source code by LorenPechtel on Monday August 26, 2019 @12:57PM (#20801486)
That's nuke-from-orbit level stupidity!
Re:Banned C standard library functions in Git source code by mlyle on Sunday August 25, 2019 @11:28AM (#20793486)
You can build coroutines from them, too, which is really cool and useful.
Re:Banned C standard library functions in Git source code by thechao on Sunday August 25, 2019 @01:22PM (#20794149)
I did! And the ergonomics are dreadful!

https://github.com/jaroslov/coro

Re:Banned C standard library functions in Git source code by yongjik on Sunday August 25, 2019 @04:59PM (#20795548)
I don't know why I still remember these, but if you need to build coroutines in C, ucontext.h might be a better tool:

https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h...

Re:Banned C standard library functions in Git source code by anfilt on Sunday August 25, 2019 @07:19PM (#20796288)
Those are deprecated.
Re:Banned C standard library functions in Git source code by thomasjames on Sunday August 25, 2019 @03:47PM (#20795064)
I had only seen them in the context of userspace threading. I wonder what mainstream libs use them. Do you know of any?
Re:Banned C standard library functions in Git source code by fucking_tragedy on Sunday August 25, 2019 @05:15PM (#20795644)
Generators are a subset of coroutines, and coroutines are useful in lexing and parsing.
Re:Banned C standard library functions in Git source code by thomasjames on Monday August 26, 2019 @10:34AM (#20800190)
Whoops, I meant that use set/longjmp() to implement coroutines. My wording in retrospect was super unclear. Sorry!
Re:Banned C standard library functions in Git source code by vasama on Sunday August 25, 2019 @11:56AM (#20793631)
I think you mean fibers, and no you can't.
Re:Banned C standard library functions in Git source code by tlb on Sunday August 25, 2019 @12:04PM (#20793677)
Here is an implementation of coroutines on top of setjmp/longjmp: https://fanf.livejournal.com/105413.html
Re:Banned C standard library functions in Git source code by superpermutat0r on Sunday August 25, 2019 @01:19PM (#20794127)
How does it work for arbitrary arguments? What about function pointers. What about calling a coroutine inside a coroutine?

It also has a stack managed in runtime. I'm not sure that would work for any other application than the fun example here.

Re:Banned C standard library functions in Git source code by vasama on Sunday August 25, 2019 @12:15PM (#20793754)
Looks more like an implementation of undefined behaviour to me.
Re:Banned C standard library functions in Git source code by dang on Sunday August 25, 2019 @02:26PM (#20794591)
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Re:Banned C standard library functions in Git source code by monocasa on Sunday August 25, 2019 @12:24PM (#20793796)
The underlying implementations define the behavior here very well.
Re:Banned C standard library functions in Git source code by fanf2 on Sunday August 25, 2019 @04:03PM (#20795177)
Well, I would not go that far. My coroutine hack relies on “unwarranted chumminess with the implementation” (http://c-faq.com/struct/structhack.html) and there are lots of incidental things that can break it. It is best treated as an example of the principles of thread switching and stack allocation.
Re:Banned C standard library functions in Git source code by zzo38computer on Sunday August 25, 2019 @12:37PM (#20793885)
I don't use setjmp() and longjmp() often, but sometimes I do; I use goto more often than those (but still not all the time). (I want goto in JavaScript too. I figured out a algorithm to do so, but have not implemented it.)

One use of setjmp/longjmp I have used is in ZORKMID, to deal with the debugger. At the beginning of the execute() function I have:

  while(setjmp(exception_buffer));
(The semicolon is correct; the loop body is supposed to be empty.) Normally, if you enter the debugger and then you exit the debugger to continue the execution, then it will continue from where it left off, which is likely in the middle of the execution of some instruction, and may result the same error again. But, if you change the program counter before continuing execution, then the debugger will keep track of that and will use longjmp instead when continuing execution, therefore skipping the rest of the instruction that stopped.
Re:Banned C standard library functions in Git source code by pault on Sunday August 25, 2019 @03:30PM (#20794976)
What can you accomplish with goto that you can't accomplish with try/catch and custom errors?
Re:Banned C standard library functions in Git source code by hibbelig on Monday August 26, 2019 @09:05AM (#20799534)
> What can you accomplish with goto that you can't accomplish with try/catch and custom errors?

You can program in C. C doesn't have try/catch...

Re:Banned C standard library functions in Git source code by dtech on Sunday August 25, 2019 @03:57PM (#20795124)
Goto sounds like a generally bad idea in a more expressive language like Javascript. Can you give an example of some Javascript-with-goto code that would be better than vanilla Javascript?
Re:Banned C standard library functions in Git source code by zzo38computer on Sunday August 25, 2019 @04:41PM (#20795429)
I have sometimes encountered such thing (but I do not remember right now), but what I do know is that goto is more helpful in C than in JavaScript. That doesn't mean that goto isn't worth anything in JavaScript, but only that there are less circumstances where it is useful compared to the other stuff. (The same is true of macros.)
Re:Banned C standard library functions in Git source code by lcuff on Sunday August 25, 2019 @11:48AM (#20793571)
I remember setjmp() and longjmp() being the only way to do a STREAMS device driver I wrote 30 years ago. Don't know if things have changed since then. Ah, what memories.
Re:Banned C standard library functions in Git source code by CorvusCrypto on Monday August 26, 2019 @12:55AM (#20797541)
Could be wrong but I believe s lot of coroutine implementations use this as well since the call preserves the frame info in the result.
Re:Banned C standard library functions in Git source code by gnulinux on Monday August 26, 2019 @09:45AM (#20799806)
I had really fun implementing coroutines, (almost-zero cost) exceptions, iterators etc with setjmp and longjmp. I think they're too useful to be banned outright (especially since C has no view on stack) since there are cases where you need to either use them or inline assembly, but I agree that they're the evilest of evilest std C functions.
Re:Banned C standard library functions in Git source code by chris_wot on Sunday August 25, 2019 @12:03PM (#20793671)
I've always wondered why goto is actually considered harmful. I really should read the original paper by Djikstra...
Re:Banned C standard library functions in Git source code by GrumpyYoungMan on Sunday August 25, 2019 @02:09PM (#20794481)
Read David Tribble's "Go To Statement Considered Harmful: A Retrospective" instead: http://david.tribble.com/text/goto.html . It contains the entire text of Dijkstra's paper and goes over its meaning in a modern context on a paragraph-by-paragraph basis. It's very well written and makes clear the "encourages spaghetti code" argument, while true at the time, applied in a era where basic control flow constructs that we now take for granted did not exist in commonly used languages.
Re:Banned C standard library functions in Git source code by nybble41 on Monday August 26, 2019 @12:46PM (#20801349)
Thank you for the recommendation; that was a very interesting read. I find that I can't quite agree with the last "nontrivial goto" example, though. This version without explicit gotos is actually shorter, and IMHO not really any more difficult to follow:

    int parse(void)
    {   
      Token tok;
      while ((tok = gettoken()) != END)
      {   
        while (!shift(tok))
          if (!reduce(tok))
            return ERROR;
      }
      return ACCEPT;
    }
I will say that any language without goto, or where the use of goto is discouraged, should at least provide guaranteed tail-call elimination as an alternative. In this case the gotos could easily be converted into loops, but not every algorithm is so accommodating.
Re:Banned C standard library functions in Git source code by gbacon on Monday August 26, 2019 @09:25AM (#20799657)
See also Structured programming with go to statements[0] by Donald E. Knuth.

[0]: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103...

Re:Banned C standard library functions in Git source code by saagarjha on Sunday August 25, 2019 @01:35PM (#20794254)
It encourages spaghetti code.
Re:Banned C standard library functions in Git source code by Someone1234 on Sunday August 25, 2019 @02:06PM (#20794470)
Not using it can also create spaghetti code. For example the "alternatives" often suggesting for exiting a multi-tiered loop (which often add additional boilerplate, additional variables, etc that all need to be maintained/bug free).
Re:Banned C standard library functions in Git source code by FartyMcFarter on Sunday August 25, 2019 @02:13PM (#20794503)
Indeed. Despite not having actual goto, Java went out of their way to have labeled loops and the "break label_name" syntax in order to avoid this awkwardness.
Re:Banned C standard library functions in Git source code by jjuhl on Sunday August 25, 2019 @03:09PM (#20794851)
Re:Banned C standard library functions in Git source code by smcameron on Sunday August 25, 2019 @04:42PM (#20795436)
libpng uses setjmp and longjump as part of its freakin' API.
Re:Banned C standard library functions in Git source code by fortran77 on Sunday August 25, 2019 @05:05PM (#20795586)
There really are use-cases for it, especially when implementing a Forth-style interpreter in C.
Re:Banned C standard library functions in Git source code by jlg23 on Sunday August 25, 2019 @01:11PM (#20794072)
> If it's used at all these days, it's used for exception handling.

And in all of the CPS code.

Re:Banned C standard library functions in Git source code by Throw_Away_4384 on Sunday August 25, 2019 @12:29PM (#20793828)
> If it's used at all these days, it's used for exception handling.

What about co-routines?

Re:Banned C standard library functions in Git source code by f00zz on Sunday August 25, 2019 @06:10PM (#20795933)
Yeah, I remember some green threads libraries based on longjmp/setjmp.
Re:Banned C standard library functions in Git source code by saagarjha on Sunday August 25, 2019 @10:55AM (#20793321)
I see zero use of those in the codebase, so perhaps they should be banned too. Or maybe they’re not on this list because nobody was using them already?
Re:Banned C standard library functions in Git source code by susam on Sunday August 25, 2019 @11:11AM (#20793402)
I have worked in large code bases (RSA NetWitness, Oracle Database, etc.) where setjmp/longjmp were used to create macros for exception handling using TRY-CATCH-ENDTRY blocks in C.
Re:Banned C standard library functions in Git source code by saagarjha on Sunday August 25, 2019 @11:14AM (#20793416)
Personally, I feel like wrapping exception handlers in macros makes it easy for people to do unsafe things with it like dynamically allocating memory or calling system functions that can’t handle it correctly.