On Fri, Mar 18, 2011 at 5:58 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hello,<br>
<br>
When looking at the HyperSpec on those functions, it seems undefined<br>
what happens when a supplied index is not a "valid array index", thus,<br>
from 0 below the array size.  The exception is ELT, which should signal<br>
a condition of type TYPE-ERROR.<br>
<br>
In practice however, it seems that implementations attempt to signal an<br>
error condition for invalid index access.<br>
<br>
In SBCL, AREF, SVREF, CHAR, SCHAR will signal a uniform condition of<br>
type SB-INT:INVALID-ARRAY-INDEX-ERROR:<br></blockquote><div><br>Which version is this? I get this one with the latest update from Fink<br><br> (handler-case (let ((a (make-array '(2 3)))) (aref a 2 1)) (error (c) (print c)))<br>

 => #<TYPE-ERROR expected-type: BIT datum: 2> <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Index 4 out of bounds for <insert array type here>,<br>
should be nonnegative and <<insert size here>.<br>
<br>
Although a different behaviour for ELT:<br>
The index 4 is too large. [SB-KERNEL:INDEX-TOO-LARGE-ERROR]<br>
<br>
<br>
For ECL, the condition type and error message varies, and SVREF even<br>
behaves differently than the others:<br>
<br>
CHAR, SCHAR: [SIMPLE-ERROR]<br>
AREF: [SIMPLE-TYPE-ERROR]<br>
SVREF: (this differs in interpreted and compiled mode)<br>
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]<br>
Compiled mode: Returns the supplied vector instead of signaling an error.<br>
ELT: [SIMPLE-TYPE-ERROR]<br></blockquote><div><br>I have changed this. CHAR, SCHAR, SVREF and ELT now use the same error reporting function. I also fixed a typo in AREF.<br><br>SVREF in compiled mode, though, may be directly translated into a vector access, if optimization levels are large enough. In this case no error checking is performed and the value you may get is completely random, as Pascal explained. Compare<br>

<br>> (funcall (compile 'nil '(lambda (x) (svref x 3))) #(1 2 3))<br>[...]<br>Condition of type: SIMPLE-TYPE-ERROR<br>In function AREF, the index into the object<br> #(1 2 3).<br>takes a value 3 out of the range (INTEGER 0 2).<br>

[...]<br>> (funcall (compile 'nil '(lambda (x) (declare (optimize (safety 0))) (svref x 3))) #(1 2 3))<br>[...]<br>Condition of type: SEGMENTATION-VIOLATION<br>Detected access to an invalid or protected memory address.<br>

Available restarts:<br><br>Juanjo<br clear="all"></div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>