[m-dev.] for review: new method of handling failures, part 1 of 6

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Jul 6 02:35:56 AEST 1998


On 04-Jul-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > Why not do it this way:
> > 
> > 	- in runtime/mercury_stacks.h, always define a redofr slot;
> > 	  don't make this conditional on MR_USE_REDOFR.
> > 	  (This should still work fine, even when compiling with
> > 	  the old compiler.)
> > 
> > 	- in runtime/mercury_grade.h, always include `redofr_' in the
> > 	  mangled grade identifier (this prevents linking
> > 	  code compiled with the old version of the runtime with
> > 	  code compiled with the new version of the runtime)
> > 
> > (Note that even linking files compiled with the new compiler with files
> > compiled with the old compiler should be fine, so long as they were
> > all compiled with the new runtime.)
> 
> The problem is not the addition of the redofr slot; I agree that by itself
> this would not present any problems. The problem is: what does fail() set
> curfr to?

bt_redofr(maxfr)

> Code generated by the old version of the compiler expects fail()
> to set curfr to maxfr, while the new version expects it to set it to
> bt_redofr(maxfr).

For all the frames created by code generated by the old compiler,
bt_redofr(maxfr) will be the same as maxfr.
For all the frames created by code generated by the new compiler,
bt_redofr(maxfr) is the correct choice.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.



More information about the developers mailing list