Re: Bug in make-shared-array.

[Neil Jerram]

Kevin Ryde <address@hidden> writes:

> "Steve Juranich" <address@hidden> writes:
>>
>> Are there any workarounds for this?
>
> There's something evil happening, I can't tell what it is.  Marius was
> the last to give the array bits a prod, he might be able to say.

I've fixed this in CVS now:

        * unif.c (scm_make_shared_array): Don't use SCM_I_ARRAY_BASE when
        oldra is not an array.  (Reported by Steve Juranich.)

But there's more dodgy-looking code in the same function: 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),
whereas in the non-array case this -

      old_base = old_min = 0;
      old_max = scm_c_generalized_vector_length (oldra) - 1;

- suggests (inclusive, inclusive).  And at line 899 this code -

      if (s[k].ubnd < s[k].lbnd)
        {
          if (1 == SCM_I_ARRAY_NDIM (ra))
            ra = make_typed_vector (scm_array_type (ra), 0);
          else
            SCM_I_ARRAY_V (ra) = make_typed_vector (scm_array_type (ra), 0);
          scm_array_handle_release (&old_handle);
          return ra;
        }

- suggests that the function will do something completely different if
one of the dimensions of the new array has a negative increment.

Anyone care to comment or to concoct new tests to explore these?

     Neil