You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On 32-bits architectures, usize is 32-bits, by definition, so any conversion from a larger type into this will drop some bits. On 64-bits architecture, converting from 128-bits to 64-bits will also lose bits. It seems that it's only used for key paths computations, so for instance on 64-bits, that would require a static access in a list at an index >= 2**64 to cause an issue, so it's rather unlikely to happen, but it's still a real bug.
The text was updated successfully, but these errors were encountered:
Probably worth testing if we can change that function to only handle usize and not cast the type integer types, like it does now. So only return Some for Value::usize.
I wrote it like this originally because I was worried about integer literals defaulting to i32 would be an issue but I haven't actually tested that.
On 32-bits architectures,
usize
is 32-bits, by definition, so any conversion from a larger type into this will drop some bits. On 64-bits architecture, converting from 128-bits to 64-bits will also lose bits. It seems that it's only used for key paths computations, so for instance on 64-bits, that would require a static access in a list at an index >= 2**64 to cause an issue, so it's rather unlikely to happen, but it's still a real bug.The text was updated successfully, but these errors were encountered: