bugnums (er, bignums)

[sandra%orion@cs.utah.edu (Sandra J Loosemore)]

I realize that running out of memory is a more general problem, and in fact
my main concern in bring this issue up was the representation issue and the
fact the CLtL defines constants and states (or recommends) minimum values
for the sizes of other kinds of objects, such as arrays and floats.
If, as some people have pointed out, having a stated limit on integer 
size would be silly because "there's nothing you can do once you run out 
of memory anyway" (or comments to that effect), than it is equally silly 
to specify limits on the size of these other objects.

I am *not* proposing any minimum limits on the *number* of objects an
implementation can support:  this is purely an issue of the *size* of a
single object.

As a secondary issue, I thought that clarifying the semantics of integer
overflow might be useful to those of us working with small implementations
on small machines; in my case, a M68K box with a meg of memory.  It's 
unlikely that I'd be able to fit a full CL on this machine and I think 
that there are other features far more important to the "spirit" of the 
spec than support for huge bignums.  (I'm all for adhering to the "spirit" 
of the spec, particularly since I don't have much chance of adhering to 
the letter!)  The point is, I can make anybody's bignum implementation 
overflow, whether the maximum number of bits I can have is 32 or 
most-positive-fixnum.  It just happens a lot more often if the limit is 32.  

Incidentally, I can think of a few other potential problems with trying 
to allocate large objects, other than the obvious representation or
running-out-of-memory problems.  For example, your operating system may 
impose a limit on the size of contiguous memory block you can snarf up.  
(I've already run into this using a C compiler with 16 bit ints -- malloc 
takes an "int" sized argument....)  Or, your Lisp compiler may assume 
that 16 bits is sufficient to represent the displacement used for 
indexing into an array.

-Sandra
-------