IF expression bug

There appears to be a problem with handling expressions that use both < (less than) and > (greater than) in that order.

Repro 1
WORKS: IF Sys$Year>2013 THEN ECHO OK
WORKS: IF Sys$Year<2015 THEN ECHO OK
WORKS: IF Sys$Year>2013 AND Sys$Year<2015 THEN ECHO OK
FAILS: IF Sys$Year<2015 AND Sys$Year>2013 THEN ECHO OK

Repro 2
WORKS: IF 0<1 THEN ECHO OK
WORKS: IF 1>0 THEN ECHO OK
WORKS: IF 1>0 AND 0<1 THEN ECHO OK
FAILS: IF 0<1 AND 1>0 THEN ECHO OK

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.

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…

Works ok with spaces around the <

if 0< 1 AND 1>0 then echo ok

works so if the first character after the < is not a space then what is inside the <> is seen as a variable

It doesn’t work for

if 0 <= 1 AND 1 > 0 then echo ok

because there’s no space after the <. Don’t see a work around for that.

Other than to reverse the order of the two tests.

IF Sys$Year<2015 AND Sys$Year>2013 THEN ECHO OK

At work so can’t test, how about:

IF "<Sys$Year>"<2015 AND "<Sys$Year>">2013 THEN ECHO OK

Nope doesn’t work.

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.

IF <Sys$Year><2015 THEN IF <Sys$Year>2013 THEN ECHO OK

if the first character after the < is not a space then what is inside the <> is seen as a variable

If that is the case, the check needs changing to “if a space exists between < and >”

It’s probably goes through GSTrans before evaluating the expression so the expression evaluator never sees the problem.

edit:
That looks like it.

DIM buf% 256
SYS "OS_GSTrans","0<1 AND 1>0" buf%, 256 TO ,A$
PRINT A$

prints “00” and

DIM buf% 256
SYS "OS_GSTrans","0< 1 AND 1>0" buf%, 256 TO ,A$
PRINT A$

prints “0< 1 AND 1>0”. Maybe GSTrans should ignore variables which start with a non alpha character.

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:

625:         CMPNE   R1, #13
626:         CMPNE   R1, #10
627:         CMPNE   R1, #0

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

If you look here then it looks like the rules for system variable names are:

• Must not contain ‘#’ or ‘*’ characters (since they’ll be interpreted as wildcards)
• Are space or control-character terminated (anything <= ASCII 32)
• Must not be zero-length

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.

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 >=.