Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!lll-winken!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Bugs in perl 3.0 pl 8 -- return statement
Message-ID: <7111@jpl-devvax.JPL.NASA.GOV>
Date: 19 Feb 90 20:18:34 GMT
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 56


In article <TOM.90Feb17084626@hcx2.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes:
: setjmp()/longjmp() must go. This is non-negotiable. :-) e+9.

I confess I like Ada exceptions a lot better too.

:    1) You were right, VOLATILE was not being defined as volatile, but fixing
:       this did not make the problem go away.

I can see another Configure test coming...    *sigh*

:    2) There are goto's in the if (setjmp()) code. These gotos imply that the
:       entire body of the routine is reachable following a setjmp(), not just
:       a few little sections of code.

Yes, but it's in a loop anyway, so that's true whatever.  And gotos are just
C's little way of telling you it wishes it had a real exception mechanism
that would let you exit blocks by default instead of restarting them...

:    3) The variables gimme, sp, retstr, tmps, go_to, and newsp are not
:       declared volatile and are also not necessarily restored correctly
:       following the longjmp (for some of them, it depends on whether or not
:       any of the switch body is executed, and that depends on the value
:       returned from longjmp).

Variables gimme and sp are function parameters, which is why I overlooked
them.  Presuming JMPCLOBBER is defined, retstr, newsp and go_to are
always taken care of if you assume that the longjmp() never returns a
value that isn't handled by the switch, which it doesn't (but I ought
to have a default case for paranoia reasons anyway.)  tmps is a scratch
variable, and is only used locally, never over a setjump()/longjmp().

It looks like your problem was either gimme or sp.  Probably sp.  They
will both be volatilized.

:    4) When I declared these 6 variables VOLATILE, the code started working
:       perfectly.

If you could tell me if it keeps working with only gimme and sp volatilized,
I'd be much obliged.  I'm not planning on volatilizing the others.

:    5) I don't actually know what specifically was happening, I stopped
:       working on it once I got it to work in step 4, but one other
:       experiment I made is worth reporting. I made 6 volatile variables to
:       save these six values in, and did saves and restores around the
:       setjmp() calls, and I *still* got the panic messages. My two best
:       theories are a compiler bug, or one of these variables is really
:       updated prior to the longjmp and wants to keep its updated value, not
:       the value it had when the first setjmp() was called.

Neither gimme nor sp is updated at any time in the routine, let alone
between setjmp() and longjmp().  And the others are supposedly accounted for.

Thanks for the input.

#5, er, I mean, Larry