[Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals
mm_lists at pulsar-zone.net
Fri Mar 18 16:58:24 UTC 2011
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
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?
More information about the ecl-devel