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

[Matthew Mondor]

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)
&OPTIONAL).
#<TYPE-ERROR {61C844B1}> 

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
and <2.

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
soon.

> 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.

Thanks again,
-- 
Matt