Thanks for the fix in 0.46.7. There are a couple more subtle problems having to do with bounds checking (one of which may be there by design).
Bounds checking occurs in the function array_rangeop_getrange() starting line 536:
firstitem = x->x_onset;
if (firstitem < 0)
firstitem = 0;
else if (firstitem > a->a_n)
firstitem = a->a_n;
if (x->x_n < 0)
nitem = a->a_n - firstitem;
else
{
nitem = x->x_n;
if (nitem + firstitem > a->a_n)
nitem = a->a_n - firstitem;
}
So unlike tabread which clips indices from 0 to n-1, this clips the onset from 0 to n, which means an onset greater than (n-1) gets a range with 0 items. I think this might be by design, but I wanted to check because a range with 0 items does something funny in the min/max array objects.
So first off, in these lines (starting line 746):
for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
i < nitem; i++, itemp += stride)
if (*(t_float *)itemp > bestf)
bestf = *(t_float *)itemp, besti = i;
If the input range has 0 items (i.e. if nitems is set to zero manually, or if the onset is greater than n-1), the for-loop condition i < nitem is never true, so the value output is going to be the bestf init value -1e30 (likewise with +1e30 in the min function). Since this a value that doesn't point to anything in the array, I wonder if it would be better not to output anything (or maybe a bang) in those cases.
Second, the value x->x_rangeop.x_onset is not bounds checked, so when you do this (line 750):
outlet_float(x->x_out2, besti + x->x_rangeop.x_onset);
if x_rangeop.x_onset iss out of range, you're going to output an erroneous index value, which could be negative or greater than n. firstitem is bounds-checked from the onset by array_rangeop_getrange() -- would it be possible to use that instead?
This suite is really a wonderful addition to Pd, and adds so much new functionality to vanilla.
Many cheers!
Matt