Ivan is not joking about the overflow, it is in my experience how it works in most languages.
Yes, overflow errors suck.
This is one of those situations where it’s on the developer to ensure values going in are sanity checked, and IMHO it makes sense. If every time you set a property it is sanity checked, that’s CPU your wasting and slowing down your application.
Integer literals in source code (like 277) are 32 or 64 bits (depending on the bitness of the platform being built for). Converting a wider integer value into a narrower variable necessarily causes a loss of precision.
Xojo can warn you about conversions that may cause a loss of precision. From the “Project” menu select “Analysis Warnings”, then put a tick in the box next to “Converting from Item1 to Item2 causes a possible loss of precision, which can lead to unexpected results”.
value, 277, is known at compile time & could generate a compiler warning / error about overflow
Xojo would need to alter the compiler to generate an error about this
Pretty sure it already can warn about this but most people likely have it disabled
at runtime there’s no way Xojo could change the behaviour as it could break existing code
some cryptographic algorithms rely on a certain behaviour on overflow/underflow
as for user input he’ll have to range check it himself
function inRange( extends ui8 as Uint8, value as integer ) as boolean
return (value < 0 or value > 255) = false
function inRange( extends ui16 as Uint16, value as integer ) as boolean
return (value < 0 or value > 65535) = false
function inRange( extends i8 as int8, value as integer ) as boolean
return (value < -128 or value > 127) = false
but DO NOT do one for EXTENDS INTEGER - just the explicitly sized types
in the compiler ? Its written in C++ so this doesnt apply in the same way
What I cant say is what settings are used for the C++ compilers to know if they treat such obvious issues as compiler errors or warnings
That might depend on what version of the compiler they are using on each platform