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

Avoid silently truncating BigInt to Int #1066

Merged
merged 1 commit into from
Apr 15, 2019
Merged

Conversation

aswaterman
Copy link
Member

  • Introduce internal helper castToInt, which issues an error when the input
    BigInt can't be represented as Int.

  • Use castToInt wherever we were using toInt in a potentially unsafe way.

Technically, this is an API modification, since previously users could have done such things as UInt.apply(BigInt.pow(2, 32)), which would have silently wrapped around and extracted bit 0.

Type of change: other enhancement

Impact: API modification

Development Phase: implementation

Release Notes

@aswaterman aswaterman requested a review from a team as a code owner April 13, 2019 00:55
@aswaterman aswaterman force-pushed the safe-cast-from-bigint branch from 2b5b360 to b616a39 Compare April 13, 2019 05:30
Copy link
Contributor

@edwardcwang edwardcwang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appears sane to me and passes tests. @ducky64 @jackkoenig Any comments?

Copy link
Contributor

@ducky64 ducky64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Another idea might just be to represent everything as BigInts internally. It's more consistent, though I also doubt one will ever need to shift by over 2^32 positions or index into such a long bitvector.

@aswaterman
Copy link
Member Author

There are still some places we'd need to truncate to Int, e.g. since Vecs are backed by Scala Vectors. And other CAD tools barf on very wide Verilog arrays anyway. So, I don't think switching to BigInts internally would bear much fruit.

- Introduce internal helper `castToInt`, which issues an error when the input
BigInt can't be represented as Int.

- Use `castToInt` wherever we were using `toInt` in a potentially unsafe way.
@edwardcwang edwardcwang force-pushed the safe-cast-from-bigint branch from 850dc78 to 5039e19 Compare April 15, 2019 19:49
@edwardcwang edwardcwang merged commit a4a29e2 into master Apr 15, 2019
@edwardcwang edwardcwang deleted the safe-cast-from-bigint branch April 15, 2019 20:07
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 this pull request may close these issues.

3 participants