15:02 <Guest30> Hi guys, I want to ask a stupid Math question, the result of t = (1 << 64) - (1 << 13) - 1 in Go is 18446744073709543486 (UInt64), but in Crystal it is -8192 (Int32), how should I solve this problem? Thanks a lot!

15:03 <Guest30> (1 << 64) - (1 << 13) - 1

15:04 <FromGitter> <Blacksmoke16> you just wanting UInt64 max value or?

15:07 <Guest30> @Blacksmoke16 Hi, I want to get the same result of Go const RejectAfterMessages.

15:08 <FromGitter> <moe:busyloop.net> hm, when you force it to u64, it gives me Arithmetic overflow

15:08 <FromGitter> <moe:busyloop.net> does go have no overflow checking? 🤔

15:09 <FromGitter> <Blacksmoke16> making them `_u128` works but is off by 63

15:09 <FromGitter> <moe:busyloop.net> but as smoke said, if you just want `UInt64::MAX` then that gives you exactly that

15:10 <Guest3050> BITS_PER_LONG = 64; COUNTER_BITS_TOTAL = 8192; COUNTER_REDUNDANT_BITS = BITS_PER_LONG; COUNTER_WINDOW_SIZE = COUNTER_BITS_TOTAL - COUNTER_REDUNDANT_BITS; REJECT_AFTER_MESSAGES = UInt64::MAX - COUNTER_WINDOW_SIZE - 1_u64

15:10 <Guest3050> Another method can be obtained, but I prefer the shift operation. :)

15:10 <FromGitter> <moe:busyloop.net> i'm sure there is a plausible explanation for that (but that would have to come from someone way smarter than me) 🤔

15:13 <FromGitter> <Blacksmoke16> yea not sure

15:13 <FromGitter> <moe:busyloop.net> guest3050, that go-code seems to rely on an integer overflow. maybe that's normal practice in go, but feels rather questionable to me.

15:13 <FromGitter> <Blacksmoke16> could also just hard code the value and call it a day

15:14 <FromGitter> <moe:busyloop.net> why hardcode when we already have a const exactly for that 🤷

15:15 <FromGitter> <Blacksmoke16> just to ensure its the exact same value as Go. seems to also be off a bit so might have some other meaning :shrug:

15:15 <FromGitter> <moe:busyloop.net> ah, good point indeed

15:16 <Guest30> @Blacksmoke16 @moe:busyloop.net ok, thank you for your answer, thank you for yours help :)

15:18 <FromGitter> <moe:busyloop.net> reminds me of my fun with json parsers, which randomly mutilate large numbers depending on how the library author felt that day. ⏎ (some truncate to 53 bits, some to 64 bits, some not at all)

15:20 <FromGitter> <moe:busyloop.net> why would you specify exact number-boundaries in the most used data-transport format anyway - as if anyone cares about such details 🤷

15:24 <Guest3010> @moe: busyloop.net sounds like fun! :) I'm making a WireGuard like thing and I'm trying to figure out, https://github.com/torvalds/linux/blob/master/drivers/net/wireguard/messages.h#L42 https://github.com/WireGuard/wireguard-go/blob/master/device/constants.go#L16

15:24 <FromGitter> <RespiteSage> @Guest30 If you just want arithmetic with overflow, you can use `&-`. But the result is still off by 63, like Blacksmoke said: https://carc.in/#/r/e4aq

15:25 <FromGitter> <moe:busyloop.net> why not copy the C-code instead of the Go-code? :)

15:25 <FromGitter> <moe:busyloop.net> `REJECT_AFTER_MESSAGES = U64_MAX - COUNTER_WINDOW_SIZE - 1` should translate to crystal 1:1, no overflows needed

15:26 <FromGitter> <moe:busyloop.net> `REJECT_AFTER_MESSAGES = UInt64::MAX - COUNTER_WINDOW_SIZE - 1`

15:27 <Guest3010> Ok, thanks a lot Benjamin Wade @RespiteSage let me learn more \O/ , @moe:busyloop.net Haha yes, but I prefer one line of code.

15:30 <Guest3010> Bye, have a good day:)   =*  (y)

15:31 <FromGitter> <moe:busyloop.net> same :)

16:27 <FromGitter> <naqvis> > *<Guest30>* Hi guys, I want to ask a stupid Math question, the result of t = (1 << 64) - (1 << 13) - 1 in Go is 18446744073709543486 (UInt64), but in Crystal it is -8192 (Int32), how should I solve this problem? Thanks a lot! ⏎ ⏎ that's not correct statement. Golang generated untyped int has same value with what you get from Crystal. Both yields `18446744073709543423` ⏎ ⏎ Go Playground:

16:27 <FromGitter> ... https://go.dev/play/p/2513-JtZtGW ... [https://gitter.im/crystal-lang/crystal?at=637cf875326f06602c5de6a6]

19:58 <Ober> ~

19:58 <Ober> -)0\''''

19:58 <Ober> </cat>

20:35 <SamantazFox_> naqvis: this is because `x << n` will return 0 if `n` is greater or equal to the number of bits in `x`

20:36 <SamantazFox_> https://play.crystal-lang.org/#/r/e4dc

20:38 <SamantazFox_> you need to specifiy that your 1st integer (which is shifted left by 64) is an int 128, then the compiler will determine that the whole equation results in an int 128

22:10 <SamantazFox> naqvis Damn sorry, I realized that you were replying to a guest...

22:11 <SamantazFox> I hate how it looks like on the IRC side