[MLton] Memory problems with latest CVS?

[Matthew Fluet]

> So, I propose to change the size of a small bignum back to 1 and to
> not export MLton.IntInf.size.

Sounds good.  MLton.size does the "right thing" on an IntInf.int, correct?
If so, there doesn't seem to be any reason for MLton.IntInf.size to be
exported.

> > It makes sense that we wouldn't see it until we had a space leak.  Note
> > how initRes works:
> ...
> > We always give the result the entire rest of the heap (not exactly the
> > requested bytes).
>
> I'm not sure why we do this.  It doesn't seem necessary, since we
> calculate the max needed size.  It would seem to be advantageous from
> a debugging perspective as well.
>
> A couple of other thoughts on making it easier to catch bugs like this
> in the future.
>
> * Could we put an assert into initRes (and other places) to catch this?

I was thinking of putting an assert in setFrontier, which would assert
that the new frontier was never more than the old frontier + bytes.
I don't think an assert in initRes really helps -- we would need
to duplicate the logic for needed size (in which case its not really an
independent test).

> * Could we tell gmp to blow up if it does a realloc?

That would probably be useful.