scm_must_realloc mallocated count in 1.6

[Kevin Ryde]

There's a bit of a bug in scm_must_realloc and its scm_mallocated
counting in 1.6.

If you tell scm_must_realloc to decrease the size of a block, it
doesn't change scm_mallocated count, so when you later report the new
size in the free, the final scm_mallocated is off by the difference
(ie. bigger than it should be).

This occurs in the core with bignums when scm_i_adjbig trims off
excess digits from the end of a block.  It might happen with
applications, though perhaps realloc to decrease isn't too common.

A little loop that shows the problem is

    (while #t
      (ash 1 256)
      (gc)
      (pk (assq-ref (gc-stats) 'bytes-malloced)))

The count printed keeps going up.


I'm inclined to remove the short-circuit

        if (size <= old_size)
          return where;

from scm_must_realloc, ie. if you ask to decrease a block then
actually do it, which is what 1.8 has now.

The alternative would be to leave no realloc() on decrease, but do
adjust scm_mallocated.  That would mean scm_mallocated doesn't reflect
the amount of malloc actually in use, which wouldn't be a good thing
for the mtrigger stuff.