Shouldn't this Cause an exception?: var i as Uint8 = 277

Xojo
1

Xojo is causing me to go bald. Using Xojo 2019 Release 3. Desktop app.

should this not cause an exception?

var i as Uint8 = 277

From memory:
Unsigned Integer8 is 1 byte / 8 bits. Max Value 255.
[dot]Net language is system.Byte
…right… ??

what I receive is: i = 21 something overflowed.

it is okay to say that I am smoking crack. Please… just smack the crack pipe out of my hands.
…No donut for you…

…BUT…
if this is a bug. Any suggestions on validating user input? which is currently a string. TextField.
I’m working in 1 byte… chunks.

~ Thank you in Advance ~

2

It just ignores the overflowed bits, sounds normal

if textfield.text.value > 255 then
'Handle error
end if
3

Thank you for the suggestion! I was going down the wrong road.

I hope you are joking about the overflow. :expressionless:

Thank you again for your input!

4

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.

2 Likes
5

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”.

1 Like
6

Then I must be spoiled with the .net framework. I was expecting an Exception to be thrown. Something similar to a OverflowException.

But with this new information… I will revise my approach. Nonetheless I really appreciate all of your input.

1 Like
7

The value is known at compile time and the compiler should throw an error.

8

Nope
Xojo doesnt cause exceptions on overflow or underflow
it will just wrap

9

Swift throws an error, which I find more accurate.

2 Likes
10

Swift

 var x : UInt8 = 277
 Integer literal '277' overflows when stored into 'UInt8'

As it should be,

var x : UInt8 = 255
x+=1
Arithmetic operation '255 + 1' (on type 'UInt8') results in an overflow

also as it should be

11

with a literal like that could Xojo throw an error ?
very possibly
but someone would need to file a feature request and the compiler person there would need to implement it

and, how much existing might it break ?
not even a wild guess

12

a-ha

1 Like
13

Well, having the value before compiling is one thing, but, what happens in the case exposed by OP?

14

Not sure I understand your question. Swift will throw an error if a datatype over/under flows its bounds

In the case of a language that DOESN’T enforce this, (such as it seems is Xojo), the developer has no way of insuring the value meets the need. (X=277 really returns 21?)

15

Xojo can warn of conversions that lose information, as I mentioned.

16

var i as Uint8 = 277

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

1 Like
17

That’s true, at runtime it is on the developer to validate user input and to catch errors caused by user input that doesn’t conform to the value type.

18 
function inRange( extends ui8 as Uint8, value as integer ) as boolean
return (value < 0 or value > 255) = false
end function

function inRange( extends ui16 as Uint16, value as integer ) as boolean
return (value < 0 or value > 65535) = false
end function

function inRange( extends i8 as int8, value as integer ) as boolean
return (value < -128 or value > 127) = false
end function

but DO NOT do one for EXTENDS INTEGER - just the explicitly sized types

… and so on

19

How many of these silent (over/under flow) errors exist in the compiler and IDE that could be fixed if this was intentionally exposed?
I’m not genius enough to speculate.

1 Like
20

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