Operators perform differently depending on whether they are in a 'constant-folded' expression or not.

For example, the multiplication operator, when the operands are the two constants, 65536 and 32768, gives the result 2147483648. When the variable A% contains the value 65536, the multiplication operator, when the operands are A% and the constant 32768, gives -2147483648.

Apologies for necroposting. I don't think this is so much a bug as it is working as intended. In a language with stricter typing like C, multiplying an integer by an integer will always result in an integer. In the case of overflow, it'll act differently if the types of the operands were floats or something. Same going here: it decides that the result is to be an integer because you're passing two integers. In the case of an overflow, the result is casted straight into an integer. It just doesn't seem right to us because everything is implicit. In the case of constant-folding, the compiler assumedly treats every numerical literal as a real (same as unsuffixed variables by default.) The compiler has an expression optimizer which converts a literal expression into its literal result at compile time, so 65536*32768 becomes 2147483648 due to the compiler assuming numeric literals are realtype. TL;DR Probably isn't a bug, we just don't have enough info to make a concrete conclusion.

A better example:

A#=2147483648
PRINT A# OR 0

Since the value of A# is outside the range of integers in SB, it is changed to the nearest 32 bit signed integer, 2147483647.

PRINT 2147483648 OR 0

This causes an overflow error during compilation, instead being converted to the "correct" result.

And by 'changed', 12Me21 means the binary for the value used has 32 bits inverted from the binary for the value given - as a 32-bit operand to a bitwise operator, the bug could hardly be worse.

And by 'changed', 12Me21 means the binary for the value used has 32 bits inverted from the binary for the value given - as a 32-bit operand to a bitwise operator, the bug could hardly be worse.

That's what I thought at first. But actually, since 2147483648 is stored as a floating point number, it can't just be truncated to convert to a 32 bit integer, so they chose to set it to the nearest possible value. It's not just inverting all the bits. Anything above 2147483647 is converted to 2147483647.