corruption of numeric constants within for-loop (by instruction counter?)

[shao113]

Note: I'm using Windows 7 64-bit.

This is a strange issue. It seems that if the first command within a for-loop starts(?) with a numeric constant, it will be corrupted (each iteration). The "corrupted" number seems to correspond with the instruction counter, as it is larger relative to how many instructions precede it.

//bad
for(i=0;i<1;i++)
{   
    debugger(222);
}

//bad
for(i=0;i<1;i++)
{   
    debugger(castlit(222));
}

//ok
for(i=0;i<1;i++)
{   
    get(); 
    debugger(castlit(222));
}

//ok
for(i=0;i<1;i++)
{   
    xx=11;
    debugger(castlit(222));
}

//ok
for(i=0;i<1;i++)
{   
    debugger("test"+222);
}

//bad
for(i=0;i<1;i++)
{   
    debugger(222+"test");
}

//bad
clear();
for(i=0;i<1;i++)
{   
    text(1, 1, "test"); //x-value is corrupted
}
wait();

//ok
clear();
one=1;
for(i=0;i<1;i++)
{   
    text(one,1,"test");
}
wait();

[swordmaster2k]

I can confirm that it acts in this way and I will try to look into it when I get the chance.

[shao113]

I did some snooping, and I think it might have to do with this stray semicolon in yacc.txt (line 489):

int ictr = CProgram::m_pyyUnits->size(); - 1;

[swordmaster2k]

Value of constant in for loop is directly related to the position of the closing brace in m_units.

Solution: The issue was caused by this line under the line_terminator LCURL rule:

    i->num = CProgram::m_pyyUnits->size(); 

Which was always referring to the machine unit 1 step up on the stack and not the opening brace of the for loop. Basically it was overwriting the "255" constant value with the position of the opening brace, it still worked at run time because the brace positions are corrected again. The corrected version reads:

    (i - 1)->num = CProgram::m_pyyUnits->size();

I've tested your sample against the fix and it works as expected along with several other test runs. A trivial bug, but a bug non the less.

Closed