IF expression bug
Jon Abbott (1421) 2652 posts |
There appears to be a problem with handling expressions that use both < (less than) and > (greater than) in that order. Repro 1 Repro 2 At a guess RISCOS is trying to expand what’s between < and >. It’s reproducible right back to RO3.1 and possibly earlier, so has been around a while. |
Jeffrey Lee (213) 6048 posts |
Yeah, that sounds like it could be trying to interpret it as a variable. What happens if you add a space on either side of the operators? I’m hoping the variable substitution code isn’t completely brain-dead… |
Colin (478) 2433 posts |
Works ok with spaces around the <
works so if the first character after the < is not a space then what is inside the <> is seen as a variable |
Colin (478) 2433 posts |
It doesn’t work for
because there’s no space after the <. Don’t see a work around for that. |
Chris Johnson (125) 825 posts |
Other than to reverse the order of the two tests. |
Rick Murray (539) 13872 posts |
At work so can’t test, how about:
|
Colin (478) 2433 posts |
Nope doesn’t work. |
Dave Higton (1515) 3555 posts |
It reminds me of the old days of Z80 assembly language. LD HL, nn and LD HL, (nn) were of course different instructions. But if you wanted the former, and your “nn” was an expression beginning with an opening bracket, you got the latter. |
David Pitt (102) 743 posts |
|
Jon Abbott (1421) 2652 posts |
If that is the case, the check needs changing to “if a space exists between < and >” |
Colin (478) 2433 posts |
It’s probably goes through GSTrans before evaluating the expression so the expression evaluator never sees the problem. edit:
prints “00” and
prints “0< 1 AND 1>0”. Maybe GSTrans should ignore variables which start with a non alpha character. |
Jon Abbott (1421) 2652 posts |
Is this the source that’s doing the check for expansion? If so, can’t it be fixed by adding “CMPNE R1,#32” into this section:
|
Colin (478) 2433 posts |
Seems to me the fix wants to go after line 614. 613 and 614 ignores the variable if it starts with ‘>’ or ’ ‘. Best solution I can see is ignore the variable if it doesn’t start with an alpha character, but it doesn’t really fix anything eg 2013<sys$year AND <sys$year>=2014 would still fail it appears that a variable starts with ‘<’ and ends with the next ’>’if the ‘>’ isn’t found then it’s deemed not to be a variable |
Jeffrey Lee (213) 6048 posts |
If you look here then it looks like the rules for system variable names are:
Once OS_GSTrans has found what looks like a variable name (and after it’s failed the ‘is this an escaped ASCII code’ test) it will call VarFindIt, i.e. OS_ReadVarVal. OS_ReadVarVal copes with wildcarded names, so it looks to me like OS_GSTrans will also cope with wildcarded names (worth checking!). If that’s the case, then the loop at line 625 simply needs updating to ignore the variable if it contains a char <= 32. The space check at line 614 is pretty redundant as the more thorough check in the following loop will immediately discard the name. |
Jeffrey Lee (213) 6048 posts |
Now fixed: https://www.riscosopen.org/viewer/revisions/logs?ident=1415134231-716686.html For compatibility with old machines, the obvious solution is to never use < or <= in an *If statement and instead just swap the operands around so that you can use > or >=. |