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

[Matthew Mondor]

On Fri, 18 Mar 2011 19:07:39 +0100
"Pascal J. Bourguignon" <pjb at informatimago.com> wrote:

> And similarly, the C standard doesn't specify either what happens when
> you reference a slot in a vector beyond (or before) the bounds of the
> vector (so called 'array' in C).
> 
> It just happens that customers of C compilers tend to expect from their
> compiler not to test out of bound errors.

Indeed I don't expect C to check these at all.

> In the case of Common Lisp, there's a declaration that allows the user
> to tell the compiler what he'd like:
> 
>   (declaim (optimization (safety 0))) ; for no runtime out-of-bound error checking
>   (declaim (optimization (safety 3))) ; for runtime out-of-bound error checking
> 
> The definition of levels 1 and 2 being left up to the implementation.

I was not aware that (safety 0) allowed implementations to totally
avoid bound checking.  Thanks for this clarifiation; it's actually a
nice feature.

In this case safety was left at 1; is it still allright for SVREF to
avoid boundary checks at this level?  Perhaps a gray area since between
0 and 3 :)

When I can, I'll then redo these tests on both SBCL and ECL using
various safety levels to ensure that at level three boundary checks
always be performed, and to list where at level 0 optimization could be
improved.

> Some other functions, when (safety 0) is specified, return an invalid
> object.  This might be better than either the original vector or an
> element of the vector.  However, SVREF is specified in such a way as to
> be highly optimizable, so it is acceptable to make it faster and let it
> return just what it has in the registers, even if it's the vector.  

This explains the unexpected SVREF results.  Thanks again,
-- 
Matt