find: -printf: reject an over-large field width instead of panicking#734
Open
leeewee wants to merge 1 commit into
Open
find: -printf: reject an over-large field width instead of panicking#734leeewee wants to merge 1 commit into
leeewee wants to merge 1 commit into
Conversation
A `-printf` field width could panic two ways: a width above `u16::MAX` reached
`core::fmt`'s `{:>width$}`, which caps the width argument at `u16::MAX` and
panics ("Formatting argument out of range"); and a width above `usize::MAX` was
`.unwrap()`-ed after a failed parse. Make `parse_format_width` fallible and
reject both — an unparseable (too-large-for-`usize`) width, and any width above
`u16::MAX` — with a graceful error instead of aborting.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #734 +/- ##
=======================================
Coverage 91.86% 91.87%
=======================================
Files 35 35
Lines 7153 7160 +7
Branches 375 376 +1
=======================================
+ Hits 6571 6578 +7
Misses 437 437
Partials 145 145 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #732
Fixes #693
A
-printffield width could panic two ways:u16::MAX(65535) reachedcore::fmt's{:>width$}, which caps the width argument atu16::MAXand panics with "Formatting argument out of range" (bug: find -printf panics issues #693);usize::MAXwas.unwrap()-ed after a failed parse (find panics (parse().unwrap()overflow) on a huge-printffield width #732).parse_format_widthis now fallible and rejects both an unparseable (too-large-for-usize) width and any width aboveu16::MAX, with a graceful error (exit 1) instead of aborting. Widths up to 65535 still pad as before.Note on the threshold: this rejects any width above
u16::MAX(65535), which is below GNU's-printfwidth ceiling (glibc'sprintfpads up to nearINT_MAX= 2147483647 and errors withEOVERFLOWabove it). 65535 is the limit of Rust'score::fmtwidth argument, so it's where padding can be done without panicking; widths in65536..INT_MAXthat GNU would pad are rejected here rather than emitting up to gigabytes of padding. This keeps the fix minimal and panic-free — a future change could pad those manually to fully match GNU.Added an integration test (
find_printf_width_too_large).