Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: Ambiguity in definition of setjmp/longjmp makes them much less useful
Message-ID: <4076:Oct901:18:5090@kramden.acf.nyu.edu>
Date: 9 Oct 90 01:18:50 GMT
References: <1597@redsox.bsw.com> <1990Oct8.031745.28651@zoo.toronto.edu>
Organization: IR
Lines: 22

In article <1990Oct8.031745.28651@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
  [ on the pain of making setjmp() reliable ]
> There just ain't no graceful way.

Actually, there is a reasonably clean way to correctly allocate
registers through jumps, without any overhead. All you need is to be
able to load and save all the registers on demand from the fixed memory
locations that they correspond to. So you keep a map of register
allocation along with the code. The fun part is figuring out how to
store the map without wasting too much memory; there are different
techniques for different register allocation strategies. I don't
remember who I heard this from.

Certainly the existing setjmp()/longjmp() is quite useless. I had to
give up on a threads library because some machines (notably a Convex,
and a Sun under gcc) simply refused to treat register variables
correctly across jumps. (I say correctly in the intuitive sense that
putting a variable into a register shouldn't change its behavior at all,
not in the ANSI sense. Declaring all variables volatile just so your
program will work? Gimme a break.)

---Dan