Repository navigation
test: accept '?' from zipinfo in zip interop test - #66979
Open
vedchaudhari wants to merge 1 commit into
Open
vedchaudhari wants to merge 1 commit into
vedchaudhari wants to merge 1 commit into
Conversation
Info-ZIP's fnfilter() prints bytes that isprint() rejects as '?'. Some builds that report UNICODE_SUPPORT still do this, for example Gentoo's without the natspec patch, so zipinfo lists the non-ASCII entry name as a row of '?' and the test fails. When the exact name is not in the listing, also accept it with the non-ASCII parts shown as '?'. The ASCII parts and the entry itself are still checked, and bsdtar still checks the exact name when extracting. Assisted-by: a closed-source coding agent Signed-off-by: vedchaudhari <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #66979 +/- ##
==========================================
- Coverage 90.58% 90.57% -0.01%
==========================================
Files 797 797
Lines 278298 278298
Branches 53523 53516 -7
==========================================
- Hits 252095 252080 -15
- Misses 16570 16576 +6
- Partials 9633 9642 +9 🚀 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.
When
zipinfois built without the natspec patch (Gentoo withUSE="unicode -natspec", for example),test-zlib-zip-interop.jsfails with:Turns out
zipinforuns every file name throughfnfilter()before printing it, and that swaps any byteisprint()doesn't like for a?(extract.c#L2895-L2924). Most distros switch that off (Debian, Ubuntu, Arch and Alpine build withNO_WORKING_ISPRINT, Fedora and openSUSE patch it, and natspec setsNO_SETLOCALE), but Gentoo without natspec doesn't, so the file shows up asunicode-??????.txt, one?per byte. The test only checks forUNICODE_SUPPORTinunzip -v, and that doesn't tell you whether names get filtered.So now, if the exact name isn't in the listing, the test also accepts it with
?in place of the non-ASCII part. The ASCII part still has to match, andbsdtarstill checks the real name when it extracts.To reproduce it, I built Info-ZIP 6.0 on Ubuntu 24.04 in WSL with the same target and flags Gentoo uses (
linux_noasm,-DUNICODE_SUPPORT -DUNICODE_WCHAR -DUTF8_MAYBE_NATIVE, no natspec). With thatzipinfothe test fails onmainand passes with this change. It still passes with Ubuntu's normalzipinfotoo.There's also #66978 for this. The main difference is that this one keeps the
UNICODE_SUPPORTcheck, so macOS still skips the non-ASCII name. Apple'szipinfoonly turns some of the bytes into?:名前(e5 90 8d e5 89 8d) comes out ase5 3f 3f e5 3f 3f, so a plain?pattern doesn't match there. I ranmain, #66978 and this branch on a macOS runner (https://github.com/vedchaudhari/node/actions/runs/40075440958):mainand this one pass, #66978 doesn't yet.@LiviaMedeiros can you check if this fixes it on your machine?
Fixes: #66975
Assisted-by: Claude Code. I reproduced the issue, reviewed the change, and tested it with both
zipinfobuilds myself.