Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.std.c
Subject: Re: setjmp/longjmp
Message-ID: <4059@ficc.uu.net>
Date: 2 May 89 16:13:57 GMT
References: <1447@cunixc.cc.columbia.edu> <1989Apr27.165319.23986@utzoo.uucp> <10189@smoke.BRL.MIL>
Organization: Xenix Support
Lines: 23

In article <10203@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes:
>Perhaps the marketplace should be encouraged to support this pseudo-standard.
>If customers refuse to buy compilers with misfeatures, even if the compilers
>are compliant, correct results can be obtained.

In article <10189@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) flames:
> Please get with the program...
> so long as the specification is unambiguous you do your customers no
> favor by deviating from it.  You will probably also lose sales when your
> compiler fails standard conformance tests.

Please read what you're following up to. Norman was recommending that compiler
writers guarantee the validity of non-register variables after a longjmp
by not doing certain optimisations around a setjmp call. The standard says
that this behaviour is undefined, so making it do the right thing is quite in
line. This will not cause a compiler to fail any conformance tests.

I agree with Norman... the dpANS handling of setjmp/longjmp is undesirable.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.