Things I've noticed in the last few days about the most negative integer in BASIC II, -2147483648:

• As the result of an arithmetic expression it is a float, though as such it can be printed in full precision (e.g. PRINT STR$ -2147483648)
• It cannot be converted arithmetically from float to integer (Too big)
• So it can only be generated as an integer from operations that only produce integers: the hex constant (&80000000) or a logical operation (effectively AND, EOR or NOT; OR cannot bootstrap.)
• DIV cannot bootstrap in principle, and in fact does not support a dividend of -2147483648 at all: with any nonzero divisor, the result is 0. Making it a pain to emulate right shifts as well as left shifts in BASIC II.
• Eight tokens seem to be the minimum to express the integer form: TRUEEOR2^31-1 (untypeable) or 1-2^31EOR1.
• Yet it can appear in an integer control variable of a FOR loop, as the stepping addition is done specially, in-place. E.g. FOR A% = -2^29 TO 1-2^31 STEP -2^29: NEXT: PRINT STR$ A%
• Stepping addition overflows without error so the number also appears in ascending FOR loops, though being greater than no integer (as the TO value is cast to the control variable's type), the loop cannot exit on this value. Indeed if 'to' + 'step' overflows the control variable's range, the loop may not terminate! (The condition is necessary but not sufficient.) FOR A% = 0 TO &70000000 STEP &10000000: PRINT ~A% DIV 2: NEXT

So despite its otherwise robust character, BASIC still has a couple of nasty bugs in store for the unwary coder.

– Greg

PRINT STR$(ABS(&80000000))
-2147483648
Gawd!

That's not a bug in BASIC, that's a fundemental underlying characteristic of any integer number system.