Talk:cpp/utility/program/setjmp

Upon return to the scope of setjmp, all accessible objects have the same values as they had when std::longjmp was executed, except for the non-volatile local variables in setjmp's scope, whose values are indeterminate.

Is this right? ANSI C says

All accessible objects have values as of the time longjmp was called, except that the values of objects of automatic storage duration that do not have volatile type and have been changed between the setjmp invocation and longjmp call are indeterminate.

indeed, well-spotted (although current ANSI C says two more things: it includes floating-point status flags and adds the no-brainer "that are local to the function containing the invocation...of setjmp") --Cubbi (talk) 03:27, 17 September 2015 (PDT)

Real-world-er example?

I kind of feel like setjmp/longjmp would benefit from a more real-world example than "weird trick for turning an if() statement into a while() loop", which is basically what the current example at all of the setjmp/longjmp pages here amounts to.

For example, in graphics codecs like mjpeg (at least the libyuv implementation) and libvpx, setjmp and longjmp are used for error handling — they wrap an error return in an if(setjmp(jump_buffer)) before starting down time-critical code paths. A problem encountered during processing triggers a longjmp(jump_buffer, 1) that rewinds the stack and enters the error condition.

Adapting something like that seems like a better demonstration of what setjmp and longjmp are actually useful for, as opposed to something that could be easily (and much more clearly) written using standard loop syntax. FeRDNYC (talk) 16:26, 19 November 2023 (PST)

The C and C++ longjmp pages do mention error handling use in the Notes section, but I agree, would be helpful to have a mini-example showing that intent. --Cubbi (talk) 09:42, 20 November 2023 (PST)