Skip to content
This repository has been archived by the owner on Sep 19, 2019. It is now read-only.

FromStr impl for U{256, 512, ...} parses from hex rather than from dec as for u{32, 64, ...} #23

Open
snd opened this issue Feb 19, 2018 · 6 comments

Comments

@snd
Copy link
Contributor

snd commented Feb 19, 2018

println!("{}", "100".parse::<u64>().unwrap()); prints 100 as expected

println!("{}", "100".parse::<U128>().unwrap()); prints 256 because FromStr for U128 assumes the string is hex and not dec.

this is unexpected and unintuitive! can lead to nasty bugs.

could we change FromStr for $uint to parse dec instead of hex to make it more in line with the std integer types?

we could add from_hex_str of from_str_radix (which would be in line with the std integer types: https://doc.rust-lang.org/std/primitive.u64.html#method.from_str_radix) for parsing uints from hex strings.

(alternatively we could add a FromHexStr trait that looks exactly like the FromStr trait but interprets input as hex)

@tomusdrw
Copy link
Contributor

tomusdrw commented Feb 19, 2018

Currently there is a https://docs.rs/ethereum-types/0.2.3/ethereum_types/struct.U128.html#method.from_dec_str method. But I agree that for Uints we should probably do this by default. Especially given that when you display them it actually prints decimals not hexes).

@snd
Copy link
Contributor Author

snd commented Feb 19, 2018

i found from_dec_str then and am using it now. assumed it would behave in line with the std integers. then found out it didn't only by accident. almost introduced a bug there. i think it's likely others will have similar assumptions and run into the same issue

@snd
Copy link
Contributor Author

snd commented Feb 19, 2018

i'd be happy to do the necessary changes. let me know! @debris what are your thoughts on this?

@debris
Copy link
Contributor

debris commented Feb 19, 2018

I have none, just don't break parity too much ;)

@snd
Copy link
Contributor Author

snd commented Feb 19, 2018

ok ; )

i'll check what this would break to see if it's even feasible to change it.

@BlinkyStitt
Copy link

I just ran into the exact issue. Did you make any progress on this, @snd?

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

No branches or pull requests

4 participants