[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