longjmp vs goto

[Peter Nilsson]

As usual, there is no substitute for knowing what you're doing and
longjmp is not the right thing when malloc and/or fopen (may) have been
called (without) the corresponding free/fclose calls between the
invocation of setjmp and the longjmp call.

Throw va_start/va_end into there too.

 

[Derk Gwen]

# But doesn't that mean that each function doesn't have to be reentrant?
# So what I understand is that if I was busy calling longjump from my
# program, and then I would get into my signal handler and call longjump

All of which is irrelevant if the signal isn't in a standard library
function. If the hardware probe function doesn't use any standard library
function directly or indirectly and doesn't depend on unsafe global
variables, then a longjmp on a signal is perfectly safe.

 

[Nick]

Throw va_start/va_end into there too.

In a universe far-far away (circa 1979) there was a boy genius who would
gladly help
you debug your code under three conditions:

1. You didnt't use signals.
2. Use didn't use setjmp() and longjmp()
3. You never,ever used unadorned scanf()

His rationale for the first two was that if you had the brass to use
them, you had BETTER know
what you're doing and thus had already shown that you didn't need his help.
It ain't for newbies, folks.

I'll leave it as an exercise to the reader to determine his rationale
for the third.

Note: that va_start/va_end were not part of the package at that time,
although I would
presume he would have included them if they had been.