[Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

[Matthew Mondor]

Hello,

When looking at the HyperSpec on those functions, it seems undefined
what happens when a supplied index is not a "valid array index", thus,
from 0 below the array size.  The exception is ELT, which should signal
a condition of type TYPE-ERROR.

In practice however, it seems that implementations attempt to signal an
error condition for invalid index access.

In SBCL, AREF, SVREF, CHAR, SCHAR will signal a uniform condition of
type SB-INT:INVALID-ARRAY-INDEX-ERROR:
Index 4 out of bounds for <insert array type here>,
should be nonnegative and <<insert size here>.

Although a different behaviour for ELT:
The index 4 is too large. [SB-KERNEL:INDEX-TOO-LARGE-ERROR]


For ECL, the condition type and error message varies, and SVREF even
behaves differently than the others:

CHAR: 4 is an illegal index to "123". [SIMPLE-ERROR]

SCHAR: 4 is an illegal index to "123". [SIMPLE-ERROR]

AREF: In an anonymous function, the index into the object 4. takes a value #(1 2 3) out of the range (INTEGER 0 2). [SIMPLE-TYPE-ERROR]

SVREF: (this differs in interpreted and compiled mode)
Interpreted mode: In function SVREF, the index into the object 4. takes a value #(1 2 3) out of the range (INTEGER 0 2). [SIMPLE-TYPE-ERROR]
Compiled mode: Returns the supplied vector instead of signaling an error.

ELT: 4 is not a valid index into the object #(1 2 3). [SIMPLE-TYPE-ERROR]


Surely that a more consistent error signal could be used among these in
the future; but my main concern is about SVREF; is its special
behaviour intentional?  In the resulting C code I was happy to see that
better optimization was possible than with AREF: inline C array access
and lack of bound checking (for AREF, a function call is used for every
access).  On the other hand, it could probably lead to unexpected
behaviour in some buggy code to return a array instead of an integer?

Thanks,
-- 
Matt