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 ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Ecls-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecls-list
