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

[Zoltan Somogyi]

> 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.

Zoltan.