[m-dev.] for review: handling layouts of compiler-generated procedures

Zoltan Somogyi zs at cs.mu.OZ.AU
Wed Oct 28 10:39:36 AEDT 1998

> But I'll take the opportunity to reiterate some points from a previous
> review: I would like to see some comments in mercury_stack_layout.h
> explaining the following two routines and/or the representation
> of the MR_sle_pred_or_func field.

There is already a comment that refers people to stack_layout.m.
Duplicating the documentation would be a bad move, since it would
lead to double maintenance problems.

> Currently the type declaration
> for that field is quite misleading -- it's declared as a enum
> of two values, but the actual representation includes values which
> don't occur in the enum.

That field *is* an enum. It just so happens that the memory location that
may hold that field may also hold either -1, or a string pointer. The
macros you quoted hide this fact; other code need not be aware of it
beyond the documented requirement of invoking the macros to check
whether or not access to some fields is safe.


More information about the developers mailing list