[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bugnums (er, bignums)
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
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.