Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support type casting for numeric values #252

Closed
kammola opened this issue Nov 20, 2020 · 5 comments · Fixed by #254
Closed

Support type casting for numeric values #252

kammola opened this issue Nov 20, 2020 · 5 comments · Fixed by #254
Assignees

Comments

@kammola
Copy link
Contributor

kammola commented Nov 20, 2020

Applying arithmetic operations and comparison between different numeric types should be allowed, e.g. ("#[ensures (result > 100 * i)]" if result is i32 and I is i32).

@kammola
Copy link
Contributor Author

kammola commented Nov 20, 2020

@vakaras

@fpoli
Copy link
Member

fpoli commented Nov 20, 2020

Lossless integer casts (e.g. i32 -> u128 etc) should already be supported.

@kammola
Copy link
Contributor Author

kammola commented Nov 20, 2020

Lossless integer casts (e.g. i32 -> u128 etc) should already be supported.

what about usize -> i32, that should be possible if we can ensure an upper bound on the value.

@fpoli
Copy link
Member

fpoli commented Nov 20, 2020

what about usize -> i32, that should be possible if we can ensure an upper bound on the value.

That's not supported, but it should be easy to encode the cast as a pure Viper Int -> Int function call, with a precondition that checks that the input value is in the range of the output type.

@fpoli
Copy link
Member

fpoli commented Nov 20, 2020

It's also easy to support numeric casts when overflow checks are disabled. It's matter of adding one branch to the encode_cast_expr in mir_encoder.rs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants