VECTOR-PUSH-EXTEND should only grow 'actually adjustable' vectors?

[Martin Karlsson]

Hello,

I may be mistaken, but I think that I have found a bug in SBCL-2.3.4 x86_64 (Linux fedora 6.2.14-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 1 00:55:28 UTC 2023 x86_64 GNU/Linux.)

*FEEATURES*: (:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT
 :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
 :SB-THREAD :SB-UNICODE :SBCL :UNIX)

This is what happens:

CL-USER> (defparameter *x* (make-array 2 :fill-pointer 0 :adjustable nil))
*X*
CL-USER> (vector-push-extend 1 *x*)
0
CL-USER> (vector-push-extend 1 *x*)
1
CL-USER> (vector-push-extend 1 *x*)
2

CLHS says, on 'Function VECTOR-PUSH, VECTOR-PUSH-EXTEND':

"Exceptional Situations:

An error of type error is signaled by vector-push-extend if it
tries to extend vector and vector is not /actually adjustable/."

'actually adjustable' is defined as:

"actually adjustable /adj./ (of an array) such that adjust-array can
adjust its characteristics by direct modification. A conforming
program may depend on an array being actually adjustable only if
either that array is known to have been /expressly adjustable/ or
if that array has been explicitly tested by adjustable-array-p."

'expressly adjustable' is defined as:

"expressly adjustable /adj./ (of an array) being actually adjustable
by virtue of an explicit request for this characteristic having
been made at the time of its creation. All arrays that are
expressly adjustable are actually adjustable, but not necessarily
vice versa."

The way I read the above leads me to believe that since I did not ask
for *X* to be adjustable, my third call of VECTOR-PUSH-EXTEND should
have resulted in an error being signaled. Is my reading correct?

[Stas Boukarev (stassats)]

(adjustable-array-p (make-array 2 :fill-pointer 0 :adjustable nil)) => T

[Richard M Kreuter (kreuter)]

Hi Martin,

The cited definition of "expressly adjustable" contains the important line: "All arrays that are expressly adjustable are actually adjustable, but not necessarily vice versa." So it's permissible that some actually adjustable arrays are not expressly adjustable.

I believe that on SBCL all vectors with fill pointers and all displaced arrays are actually adjustable, even those that are not expressly adjustable, but in principle some other implementation might offer non-adjustable vectors with fill pointers or displaced arrays. So it's potentially a portability pitfall for a program written on SBCL to depend on the actual adjustable-ness of vectors with fill pointers or displaced arrays.

(Background: the underspecified distinction between actual vs. expressly adjustable traces back to CLtL1, and derives from a disagreement between the Lisp Machine people and the "stock hardware" people circa 1982. On the MIT-derived Lisp Machines (at least the ones around when CLtL1 was being drafted), all arrays were actually adjustable, and the LispM camp pushed for adjustable arrays in Common Lisp, for whatever reasons. The non-LispM camp mostly didn't want adjustable arrays, but compromised and included them, provided that the language included declaration types that might describe and constructor syntax that might produce not-actually-adjustable arrays at the implementation's discretion. So that's what we ended up with.)