[BUG][FIX] Integer>>printOn:base: fix prevents VM crash

David T. Lewis lewis at mail.msen.com
Fri May 28 02:45:06 UTC 2004

On Fri, May 28, 2004 at 04:17:33AM +0200, Stephan Rudlof wrote:
> > an uninitialized instance of LargePositiveInteger
> > intended for use as a template for fast large integer creation (but not
> > actually used in the present Squeak image or VM).
> How should this mechanism work?
> Note: currently creating a LargeInteger by the VM fills its bytes with
> zeroes (see ObjectMemory>>instantiateClass:indexableSize:).

I'm really only guessing, but I suspect that this is something left over
from an earlier version of Squeak or its predecessors. It looks like the
idea was to have pre-built template objects for a few classes so they
could be copied rather than constructed from scratch. Most likely these
template objects could just be eliminated from the special objects array,
but I would hesitate to do this without really knowing why they got put
there in the first place.

> After fixing the plugin: what do you think about printing 'non
> normalized!' or similar added to the digits if this problem occurs then?
> Your change would cover a potential problem then (now this is the right
> thing, of course).

To be honest, I don't think it really matters. This is not going to
happen in normal usage of integers, and anyway you can see the fields
in a large integer when you view it it an inspector. I don't think it's
worth worrying about it.

I did try "Integer allSubInstances select: [:i | (i normalize == i) not]"
in a fresh image, and the only non-normalized integer in the image was
the one in the special objects array. So I think this is no big deal
as long as we don't crash the system when we inspect the special objects
array ;-)


More information about the Squeak-dev mailing list