Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: setjmp/longjmp
Message-ID: <10195@smoke.BRL.MIL>
Date: 3 May 89 10:49:08 GMT
References: <1447@cunixc.cc.columbia.edu> <1989Apr27.165319.23986@utzoo.uucp> <17179@mimsy.UUCP> <1989Apr29.232632.23997@utzoo.uucp> <10203@socslgw.csl.sony.JUNET> <10189@smoke.BRL.MIL> <1989May2.225124.12977@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1989May2.225124.12977@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Uh, Doug, he's talking about doing better than mere conformance, not about
>deviating from it.

That's okay, then -- I must have confused that with suggestions earlier
heard that existing UNIX setjmp/longjmp behavior be preserved, and there
seem to be some current implementations that don't conform to the standard.

It's harder than one might think to obtain more stringent guarantees for
what is preserved across a longjmp.  There was considerable discussion of
this in X3J11 meetings, much of which I no longer remember in detail.
I do recall that the outcome was that stricter requirements were
considered an excessive implementation burden.  If an implementer can do
better, more power to him, but portable programmers are not going to rely
on it.  Heck, they're probably not going to use longjmp much anyway.