So... the relevant line of code is line 105 of vb.c which looks like this:
else EBLOOP(I, u[i], v[k+m], zv[k]=i==m); break;
And, when you expand the macro, you get something which looks like this:
} else {
I *u= (I*)av, *v= (I*)wv;
{
I i= 0, _n= m;
for (; i < _n; i++) {
yv[u[i]]= m - i;
}
};
while (k < p) {
for (i= 0; i < m && u[i] == v[k + i]; ++i);
zv[k]= i == m;
k+= yv[v[k + m]];
} if (k == p) {
for (i= 0; i < m && u[i] == v[k + i]; ++i);
zv[k]= i == m;
}
};
break;
Roughly speaking:
av is x's integers
wv is y's integers
m is #x
k starts at 0
p is (#y)-m
zv holds the result
yv holds the "skip locations" for where to start next, in this case
yv=: 3 1 3 3 3
The problem, though, with
k+= yv[v[k + m]];
is that v comes from the right argument, which in this case has
negative values in it. So that's indexing outside the range of values
defined for yv.
It should be more like yv[v[k+m]-c] where c was computed in jtebarprep
which itself is doing something wrong for this case.
The relevant lines of code there are:
case INT: irange(m,AV(a),&ca,&da); if(da)irange(n,AV(w),&cw,&dw);
if(da&&dw){c=MIN(ca,cw); d=MAX(ca+da,cw+dw)-c;}
if(0<c&&c+d<=4*n){d+=c; c=0;} break;
The value c=MIN(ca,cw) is the value we want.
jtebarprep gets called early on, like this:
RE(d=ebarprep(a,w,&a,&w,&c));
and is declared like this:
static I jtebarprep(J jt,A a,A w,A*za,A*zw,I*zc){I
ar,at,c=0,ca,cw,d=IMAX,da,dw,m,n,t,wr,wt;
and contains this line:
*za=a; *zw=w; *zc=c;
Unfortunately, the line where c is defined happens after *zc=c; so c
will always be zero.
Another minor tidiness thing is that da and dw are pointer values into
valid memory, so the if(da) and if(da&&dw) will always be true - they
could be eliminated with no effect on the code.
Anyways, it looks like the code is part way done being revised and
that revision needs to be finished.
I believe that moving the *zc= down in jtebarprep and changing
k+= yv[v[k + m]];
to
k+= yv[v[k + m]-c];
will do the trick.
Unfortunately, fixing this will probably require a change to the
definition of EBLOOP, because there are two references to SUB0 and I
believe only the second needs to have c subtracted. And I guess every
use of EBLOOP would need to be verified to work with the new
definition...
Also the test case _2 1 E. 1 2 _1 _2 1 should be added to test/gebar.ijs
Then again, I could be wrong...
Thanks,
--
Raul
On Wed, Sep 23, 2015 at 7:34 PM, Raul Miller <[email protected]> wrote:
> I can't reproduce that bug with the steps listed in the wiki.
>
> Even after I change the code so that (y E. z) is an executable part of
> that explicit definition, there's no arguments indicated which cause a
> problem.
>
> In other words, the bug report itself needs more attention.
>
> --
> Raul
>
>
> On Wed, Sep 23, 2015 at 7:32 PM, Henry Rich <[email protected]> wrote:
>> Yeah.
>>
>> Henry Rich
>>
>> On 9/23/2015 7:30 PM, Raul Miller wrote:
>>>
>>> This?
>>>
>>>
>>> http://jsoftware.com/jwiki/System/Interpreter/Bugs#numeric_dyad_E._corrupts_memory
>>>
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
