BUG: clhs limits adherence

[Peter Keller]

Hello,

I would like to report, well, a bug of sorts.

Suppose we look at this in ABCL 1.5.0:

CL-USER(1): (values call-arguments-limit lambda-parameters-limit
multiple-values-limit (lisp-implementation-type))
50
50
32
"Armed Bear Common Lisp"

I claim that those limits are valid from the CLHS, but are
not enforced, and hence not correct, in version 1.5.0 of ABCL.

I did a cursory look through the ABCL sources and found that really only
FORMAT actually checks (well, the appropriate ones anyway) these
limits when processing the format string (IIUC).

Here is a place where the limits should have been enforced:

I tried these with (declaim (optimize (safety 3))) set.


CL-USER(2): (list 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9
10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7
8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10)

(1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8
9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6
7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10)
CL-USER(3):

Another example:

CL-USER(3): (setf *foo* (loop for i below 1024 collect i))

<big correct list as output>

CL-USER(4): (apply #'max *foo*)
1023

Another example:

CL-USER(1): (defmacro defit (name size)
  (let ((ll (loop for i below size collect (make-symbol (format nil "V~A" i)))))

    `(defun ,name  ,ll
       (list , at ll))))
DEFIT
CL-USER(2): (defit foo 1024)
FOO
CL-USER(3): (apply #'foo (loop for i below 1024 collect i))

<big correct list as output>

Another example:

(funcall #'values 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9
10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7
8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 )

<correct returned values>

I believe that these worked when they should have failed. That is the, uh, bug,
that I'm reporting. :) The only other legitimate option to believe is that
I'm silently corrupting memory somewhere because I'm blowing unchecked
limits...

In looking at the code, all of the Primitives.java functions I sampled seemed
to accept arbitrarily large numbers of arguments and handled this by allocating
memory (as it should be).

So, instead of fixing ABCL to actually honor those limits, which is a step
backwards IMHO, I propose raising them to much larger values, like
2^32 or whatever true and real value they should have.

Is there any reason why this can't be done? Like large allocated
tables that I missed in the code, etc, etc, etc?

Thank you!

-pete