[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in make-shared-array.

From: Neil Jerram
Subject: Re: Bug in make-shared-array.
Date: Sat, 11 Mar 2006 00:07:11 +0000
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]