[Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals
mm_lists at pulsar-zone.net
Fri Mar 18 18:42:04 UTC 2011
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
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
> 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,
More information about the ecl-devel