Re: Bug in make-shared-array.

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> in lines
> 872-893, this -
> 
>         if (s[k].inc > 0)
>           old_max += (s[k].ubnd - s[k].lbnd) * s[k].inc;
>         else
>           old_min += (s[k].ubnd - s[k].lbnd) * s[k].inc;
> 
> - suggests that (old_min, old_max) will be (inclusive, exclusive),

Hmm, no, this loop computes the range of valid indices into the
underlying storage vector and is not concerned with the number of
elements.  Thus, all valid indices i must satisfy old_min <= i <=
old_max.

However, trying to condense the range checking of the shared array
into just comparing the valid index ranges in the underlying vector
will not catch all violations.  For example, given a 2x2 matrix that
is stored in elements 0,1,2, and 3 of a vector

    (define a #2((0 1) (2 3)))

we can make a shared array for its first row like this:

    (define r0 (make-shared-array a (lambda (i) (list 0 i)) 2))

This array refers to elements 0,1 of the vector that stores a.

We can also make a row that has three elements:

    (define r1 (make-shared-array a (lambda (i) (list 0 i)) 3))
    r1 => #1(1 2 3)

This row wraps around and its third element is the first element of
the second row of a.

The checking done by make-shared-array will never allow accesses
outside of the storage vector, but it might allow accesses to elements
that are not part of the original array passed to make-shared-array.

This behavior might or might not be a feature, but if you really want
it, it is probably better to use array-contents explicitely.

I'm inclined not to do anything about this until starting a bigger,
more general cleanup of the code.  Thoughts?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405