LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

&H confused about what type it is

Root / Programming Questions / [.]

SquareFingersCreated:
EDIT: This bug, I now believe, is a symptom of "Operators perform differently depending on whether they are in a 'constant-folded' expression or not." http://smilebasicsource.com/forum?ftid=106 (thank you calc84maniac for helping me clarify my thoughts). Further discussion probably belongs on that thread rather than this one. It appears that &H operates as if what follows is a representation of a value of 'integer' type (e.g. &H80000000 makes a negative value), but the value generated appears to be represented in the 'floating-point' type (when applied to the expression &H80000000*0-&H80000000 (adapted from http://smilebasicsource.com/page?pid=51 by replacing X with 0x80000000), it generates the value 0, indicating floating-point).

It's not an issue with &H specifically. It's a property of the constant folding during preprocessing. If a constant integer operation overflows, it is converted to a real number automatically. Try PRINT 65536*65536 versus A%=65536:PRINT A%*A%. If you replace 0 with SGN(0), which is still an integer but not parsed as a constant, you'll find that the result is an integer after all.

You're right. The bug, more generally, is that a value expressed as a literal is processed differently from a value that is retrieved from a variable or calculation, or returned from a function.