[m-dev.] for review: direct retry
Zoltan Somogyi
zs at cs.mu.OZ.AU
Mon Oct 16 12:56:40 AEDT 2000
On 13-Oct-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> How does `MR_saved_r1(save_area)' differ from `saved_reg(save_area, 1)',
> where saved_reg() is the existing macro defined in mercury_regs.h?
> Other than by having an `MR_' prefix, of course ;-)
By my knowing about it :-(
> > + MR_EvalMethod MR_sle_eval_method:8;
>
> Standard ANSI/ISO C does not allow enum bitfields.
Ah. I could easily fix this, by making the field of type MR_int_least8_t and
casting it where it is referenced, but I would prefer not to. It would not be
too bad for this field, since it is used only once or twice, but I want to
make type_ctor_rep another 8-bit enum field, and *that* is used in lots of
places.
Is this likely to be a problem in practice? Does MSVC support enum bitfields?
> > + *problem = MR_undo_updates_of_maxfr(level_layout,
> > + *sp_ptr, *curfr_ptr, maxfr_ptr);
> > +
> > + if (*problem != NULL) {
> > + return NULL;
> > + }
> > +
> > + MR_maybe_record_call_table(level_layout, *sp_ptr, *curfr_ptr);
> > +
> > + for (i = 0; i < ancestor_level; i++) {
> > + result = MR_stack_walk_step(level_layout, &return_label_layout,
> > + sp_ptr, curfr_ptr, problem);
> > + if (result != STEP_OK) {
> > + if (*problem == NULL) {
> > + *problem = "not that many ancestors";
> > + }
> > +
> > + return NULL;
>
> What happens if you're debugging some code, and you type `retry 999'
> and get that error message, and then you try to continue debugging?
> Since it's already undone the updates of maxfr, couldn't that lead to a crash?
The updates of maxfr are undone only in a local variable (maxfr_ptr points to
base_maxfr in the caller), not the register holding maxfr or even its saved
copy. Those are updated only after the last possible point of failure.
The "unwinding" of the stack is handled the same way.
I followed your other suggestions, except one which touches code I have
already modified in another diff, which I will hold until that diff in order to
avoid a conflict.
Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list