Array types and fill pointers cause a problem

[Paul F. Dietz]

Type declarations for arrays involve the full span of the array, but functions computed on their contents only go up to the fill pointer. This causes incorrect optimizations:

(defun f24a ()
  (let ((x (make-array '(1) :element-type 'bit :fill-pointer 0))
        (y (make-array '(1) :element-type 'base-char :fill-pointer 0)))
    (equalp x y)))

(defun f24b ()
  (let ((x (make-array '(1) :element-type 'bit :fill-pointer 0))
        (y (make-array '(1) :element-type 'base-char :fill-pointer 0)))
    (declare (notinline equalp))
    (equalp x y)))

(f24a) ==> NIL

(f24b) ==> T

[Paul F. Dietz (paul-f-dietz)]

I'll add that the definition of EQUALP says:

"If two arrays have the same number of dimensions, the dimensions match, and the corresponding active elements are equalp. The types for which the arrays are specialized need not match; for example, a string and a general array that happens to contain the same characters are equalp. Because equalp performs element-by-element comparisons of strings and ignores the case of characters, case distinctions are ignored when equalp compares strings."

Reading this strictly I think it says that (equalp (make-array '(1) :element-type t :fill-pointer 0) (make-array '(2) :element-type t :fill-pointer 0)) should return NIL (since the dimensions don't match), but this seems against the spirit of equalp. SBCL returns T in this case. This should be mentioned in the SBCL documentation as a possible ANSI deviation.

[Stas Boukarev (stassats)]

It is not actually about the fill pointer but type mismatch, it doesn't take into account that zero-length arrays of different types are equalp.

[Stas Boukarev (stassats)]

ad48ecb5ececcf96079162e3f1c60491dfae0d33