[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;
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