Xref: utzoo comp.lang.c:32741 alt.religion.computers:1891
Path: utzoo!utgpu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c,alt.religion.computers
Subject: Re: Ambiguity in definition of setjmp/longjmp makes them much less useful
Message-ID: <13914:Oct920:48:3290@kramden.acf.nyu.edu>
Date: 9 Oct 90 20:48:32 GMT
References: <TOM.90Oct8071803@hcx2.ssd.csd.harris.com> <891@usage.csd.unsw.oz.au> <:_A6T46@xds13.ferranti.com>
Followup-To: alt.religion.computers
Organization: IR
Lines: 16

In article <:_A6T46@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> I think it reasonable not to guarantee longjmp behaviour from within
> signals. In fact, calling longjmp from within signals is evil. The only
> thing you should do within a signal routine is set a flag... anything
> else is a bug waiting to happen.

Correct.

> Of course, you need to do this in BSD, but BSD is buggier than a dog pound.

Say what? I've written large BSD applications that don't do anything
inside signal handlers other than set flags. Where's this ``need'' you
talk about? And if you're going to insist that BSD is buggier than SysV,
how about some proof?

---Dan