Forums Bug Reports bitwise consistency for /set &

A while ago, a regression was reported for /if & bitwise operator, which wasn't working for the full unsigned 32 bits range.

The issue was fixed for /if, but /set & also has a similar issue:

//var -s %a $calc(2^32-1),%var.bx %a & %a | if (%a & %a) echo -ag if $v1 -- $and(%a,%a)


For consistency, it should return the same value as $and(a,b).

Reading through the previous bug report about /if &, it looks like the issue was due to atoi()/strtol() in newer versions of Visual C++ behaving differently when it comes to wrapping integers.

Both /if & and /set & originally used signed 32bit ints and were never meant to match $and() or any of the other bitwise identifiers, which were added much later.

Looking at the recent /if & change, I probably should have changed it to match the wraparound behaviour of v6.35, to maintain backward compatibility. But the behaviour changed in v7.x, over ten years ago, so backward compatibility has now been broken twice. At this point, I may as well just make both /if & and /set & use unsigned 32bit ints. This change will be in the next beta.

Cool, thanks.