bug(printf): big hex values, lead to mismatch in outputs last two digits when paired with rounding
Open
Nobody has claimed this yet.
U - printf
- Dominant language
- Rust
- Stars
- 24.1k
- Forks
- 2k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 365
Description
Hi, uutils mainteners
we confirm that part of our testing, here is how can be repro
relunsec@relunsec:~/software/coreutils/target/debug$ ./printf %.f1 -0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
-1053122916685571866979180276836704323188950954005491112543109775351relunsec@relunsec:~/software/coreutils/target/debug$ gnuprintf %.f1 -0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
-1053122916685571866979180276836704323188950954005491112543109775361relunsec@relunsec:~/software/coreutils/target/debug$
as you can see uu says 51 gnu says 61, that also with the same value when removing the - sign
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported command with uutils' printf and compare it with gnuprintf, both with and without the leading minus sign. Trace the printf rounding and hexadecimal-value formatting path, then add or update coverage for this input. Done means uutils produces the same final digits as gnuprintf for the reported cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100