setjmp/longjmp

[Norman Diamond]

In article <1989Apr29.232632.23997 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:

I >>>... a very clever compiler can change save/restore conventions when
N >>>it notices the setjmp() ....
E >>
W >>This is a reasonable approach.  setjmp/longjmp are rare enough that I
S >>doubt it will slow things much.
  >
I >I and others argued, as formal public comments, that odd behavior of
S >local variables should be restricted to variables declared "register",
  >on the grounds that the only real problem is silent promotion of non-
A >"register" variables into registers, and compilers that are smart enough
  >to do that are smart enough to notice setjmp and change conventions.
P >(Dumb compilers may be generating code on the fly, meaning that they
R >can't easily go back and fix earlier code on seeing setjmp(), but such
I >compilers generally wouldn't have enough info to promote variables.)
C >People are more or less used to problems with "register" variables after
K >longjmp; extending it to all local variables breaks a lot of programs.

Interesting.  What were the formal answers?  (I'd guess that there were no
actual answers but only formal answers :-)

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.

Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp at relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-inventing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?