Skip to content

find: -printf: advance past a full char in advance_one to avoid a multibyte panic#731

Open
leeewee wants to merge 1 commit into
uutils:mainfrom
leeewee:find-fix-printf-advance-multibyte
Open

find: -printf: advance past a full char in advance_one to avoid a multibyte panic#731
leeewee wants to merge 1 commit into
uutils:mainfrom
leeewee:find-fix-printf-advance-multibyte

Conversation

@leeewee

@leeewee leeewee commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Fixes #730

advance_one read a full char via front() but then dropped it by slicing one byte (&self.string[1..]). When that char is multibyte (e.g. after a % conversion, a \ escape, or a %A/%C/%T time directive), byte index 1 is not a char boundary, so the slice panicked:

$ mkdir d; touch d/a
$ find d -printf '%€\n'
thread 'main' panicked at src/find/matchers/printf.rs:152:35:
byte index 1 is not a char boundary; it is inside '€' (bytes 0..3) of `€`
$ echo $?
101

(also \€ and %A€ / %C€ / %T€)

This advances by the leading char's UTF-8 length (c.len_utf8()) instead of a fixed 1, so a multibyte char routes through the normal handling instead of aborting — the same multibyte-aware approach #723 applied to peek. Unrecognized escapes / invalid time specifiers keep their existing behavior (a multibyte char now behaves exactly like its ASCII equivalent, e.g. \€ like \q).

Added a regression test (test_parse_multibyte_char_after_directive).

@codecov

codecov Bot commented Jun 12, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.87%. Comparing base (795d29a) to head (13da7cc).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #731   +/-   ##
=======================================
  Coverage   91.86%   91.87%           
=======================================
  Files          35       35           
  Lines        7153     7160    +7     
  Branches      375      375           
=======================================
+ Hits         6571     6578    +7     
  Misses        437      437           
  Partials      145      145           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@codspeed-hq

codspeed-hq Bot commented Jun 12, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 20 untouched benchmarks


Comparing leeewee:find-fix-printf-advance-multibyte (13da7cc) with main (795d29a)

Open in CodSpeed

advance_one read a full `char` via front() but then dropped it by slicing one
byte (`&self.string[1..]`). When that char is multibyte (e.g. a `€` after a `%`
conversion, a `\` escape, or a `%A`/`%C`/`%T` time directive), byte index 1 is
not a char boundary and the slice panics. Advance by the char's UTF-8 length so
multibyte input routes through the normal handling instead of aborting.
@leeewee leeewee force-pushed the find-fix-printf-advance-multibyte branch from 94d6c7a to 13da7cc Compare June 12, 2026 05:54
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.

find: -printf: advance_one still panics on a multibyte char (after %, \, or a time directive)

1 participant