Array types and fill pointers cause a problem
Bug #1732277 reported by
Paul F. Dietz
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
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.