Re: Bug in make-shared-array.

[Steve Juranich]

Marius Vollmer wrote:

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

Okay.  So maybe I missed something here.  Is there a workaround in place so
that the examples in the info page work?  Because right now, not all of
them do:

>From the info page:
<info>
     Dimensions can be increased by for instance considering portions
     of a one dimensional array as rows in a two dimensional array.
     (`array-contents' below can do the opposite, flattening an array.)

          (make-shared-array #1(a b c d e f g h i j k l)
                             (lambda (i j) (list (+ (* i 3) j)))
                             4 3)
          => #2((a b c) (d e f) (g h i) (j k l))
</info>

But in a guile process...
<process>
guile> (make-shared-array #1(a b c d e f g h i j k l)
                             (lambda (i j) (list (+ (* i 3) j)))
                             4 3)

Backtrace:
In standard input:
   8: 0* [make-shared-array #(a b c d e f g h i ...) #<procedure #f (i j)> 4
3]

standard input:8:1: In procedure make-shared-array in expression
(make-shared-array (quote #) (lambda # #) ...):
standard input:8:1: mapping out of range
ABORT: (misc-error)
</process>

My opinion would be that this would be higher priority as long as the info
page examples don't work (then again, I'm not a developer).  I guess an
easier fix would be to change the info page examples. ;-)

Thanks for making sure this doesn't slip through the cracks.

Gratefully,
-- 
Steve Juranich
Tucson, AZ
USA