[Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals
mm_lists at pulsar-zone.net
Sun Apr 3 18:51:04 UTC 2011
On Sun, 3 Apr 2011 09:59:17 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
> > In SBCL, AREF, SVREF, CHAR, SCHAR will signal a uniform condition of
> > type SB-INT:INVALID-ARRAY-INDEX-ERROR:
> Which version is this? I get this one with the latest update from Fink
> (handler-case (let ((a (make-array '(2 3)))) (aref a 2 1)) (error (c)
> (print c)))
> => #<TYPE-ERROR expected-type: BIT datum: 2>
Admitedly my SBCL build is starting to date (1.0.42) as it wasn't
painless to bootstrap, it doesn't suppport threads on NetBSD, and that I
barely use it lately.
However, for that test case I'm also getting a TYPE-ERROR with it:
; Asserted type BIT conflicts with derived type (VALUES (INTEGER 2 2)
On the other hand:
* (aref #(1 2 3) 3)
debugger invoked on a SB-INT:INVALID-ARRAY-INDEX-ERROR:
Index 3 out of bounds for (SIMPLE-VECTOR 2), should be nonnegative
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-INT:INVALID-ARRAY-INDEX-ERROR #(1 2 3) 3 2 NIL)
> > For ECL, the condition type and error message varies, and SVREF even
> > behaves differently than the others:
> > CHAR, SCHAR: [SIMPLE-ERROR]
> > AREF: [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: [SIMPLE-TYPE-ERROR]
> I have changed this. CHAR, SCHAR, SVREF and ELT now use the same error
> reporting function. I also fixed a typo in AREF.
Nice, I will when I can update ECL and confirm these also work for me
> 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
> > (funcall (compile 'nil '(lambda (x) (svref x 3))) #(1 2 3))
> Condition of type: SIMPLE-TYPE-ERROR
> In function AREF, the index into the object
> #(1 2 3).
> takes a value 3 out of the range (INTEGER 0 2).
> > (funcall (compile 'nil '(lambda (x) (declare (optimize (safety 0))) (svref
> x 3))) #(1 2 3))
> Condition of type: SEGMENTATION-VIOLATION
> Detected access to an invalid or protected memory address.
> Available restarts:
Yes, I think that I now understand this. It also appears that in some
particular cases AREF access will be inlined at safety=0, which is a
very nice thing too.
More information about the ecl-devel