In the code below you see I explicitly set the shown values to be i64 64-bit values. However, when it get close to the limit value, I notice some of them switching between i32 and i64 types. How can this happen? I set them to be (and always stay) i64 to explicitly to prevent overflow. start = Time…

There’s a fd = 1 in the else branch. That assigns a number of value 1 to fd and since no type is specified, it picks the default type Int32. Just changing this line to fd = 1i64 is necessary and fixes the problem.

Btw. you can add type restrictions to local variables, that would have immediately alerted you about the mismatching type (ideally it could probably even autocast assigned literals to Int64).

[image] straight-shoota: Btw. you can add type restrictions to local variables, that would have immediately alerted you about the mismatching type (ideally it could probably even autocast assigned literals to Int64). How do you do that? Please give examples. Changing the fd = 1 to fd = i64 …

NEVER DO THIS it’s in the documentation under https://crystal-lang.org/reference/syntax_and_semantics/type_grammar.html then “declaring variables” x = uninitialized Int32 x = 0 puts x x = "test" puts x this produces : Showing last frame. Use --error-trace for full trace. In test.cr:8:1 8 |…

No, please don’t use uninitialized. That’s unsafe!! The way to declare the type of a variable is the same as you declare the type of anything: x : Int64 = 1 # do stuff with x tl;dr: never, ever use uninitialize

[image] jzakiya: There’s needs to be a clear (and documented) way users can set variable types and know all math operations results will produce values of that type. I see that documentation on type restrictions is missing from the reference page on local variables . We’ll need to add that. T…

There’s needs to be a clear (and documented) way users can set variable types and know all math operations results will produce values of that type. As straigh-shoota said, the type of a op b is always a. I think that’s a pretty easy thing to remember. I was lucky here because I’ve run into thi…

See also https://github.com/crystal-lang/crystal/issues/8872 (though not quite the same thing…)

What if we automatically turn Int32 | Int64 into Int64? That is, you can’t really have a union of two integer types when one fits perfectly inside another one: you just get the bigger type. Same if you do Int8 | Int16, UInt32 | UInt64, etc. Then at least when mixing Int64 code with Int32 you’ll alwa…

Meh, maybe for 2.0. Until 1.0 I won’t experiment any more.

Another Arithemetic overflow problem

Topic		Replies	Views
Arithmethic overflow should not raise an exception Crystal Contrib	57	2458	April 28, 2020
Type must be (Int64 \| Int8), not Int32 Help & Support	13	971	March 20, 2019
First time being bitten by Crystal autocasting Help & Support	30	1577	July 25, 2022
Inconsistent document about autocasting Crystal Contrib	9	405	January 15, 2024
How to detect Arithmetic Overflow exceptions Help & Support	3	634	January 17, 2020

Another Arithemetic overflow problem

Related topics