paritytech / paritytech/parity-common

[uint, primitive-types]: Parsing from string is not what is expected

Open
#643 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Z1-question
Dominant language
Rust
Stars
311
Forks
245
PR merge metrics
No merged PRs in 30d

Description

I was using U256 as an argument with clap and I found out that my input was parsed as hexadecimal number.

I was expecting the following, however the first assert fails because num is 39.

use primitive_types::U256;

fn main() {
    let num: U256 = "27".parse().unwrap();
    assert_eq!(num, 27.into());

    let num: U256 = "0x27".parse().unwrap();
    assert_eq!(num, 0x27.into());
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the U256 string parsing entry point used by the shown "27" and "0x27" examples, then inspect any existing parsing behavior around those inputs. Done means the examples produce the expected decimal and hexadecimal values, with regression coverage for both forms.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.