Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync the minizip code from upstream #188

Open
cen1 opened this issue Mar 7, 2024 · 2 comments
Open

Sync the minizip code from upstream #188

cen1 opened this issue Mar 7, 2024 · 2 comments
Assignees

Comments

@cen1
Copy link
Collaborator

cen1 commented Mar 7, 2024

Pull in the latest minizip code

Observation: quite a few changes from the code that is currently in the repo.

  1. Diff against the old clean version to strictly document local changed and additions. Already pretty good in some places.
  2. Apply the changes to the new code
  3. Think of a way to avoid this work for future sync

Relavant issues:
#19

Slightly relavant:
#169
#107

@cen1 cen1 self-assigned this Mar 7, 2024
@Neustradamus
Copy link

To follow

@cen1
Copy link
Collaborator Author

cen1 commented Oct 12, 2024

Initial, "blindly pull from upstream" update syncing with zlib v1.3.1 tracked here: #209

Good news: it builds, tests pass.

This was not as terrible as I initially expected but some sections will need a thorough review. Biggest issue is knowing if pulling a piece of code from upstream is patching an existing minizip code or it's replacing a modification/a fix made in quazip. There are quite a few small patches touching various issues that are exclusive to quazip so reviewing commit history is mandatory.

What are the actual modifications to minizip by quazip where we need to be careful when pulling?

  • const char* filename -> voidpf file API changes
  • some methods are extended with additional flags, UTF-8 handling
  • zip.c version_to_extract change
  • ZFAKECLOSE64, autoclose modifications

Notable changes from upstream pull:

  • removal of OF macro
  • lot's of comment typos
  • some type shuffling between int, long, uLong, type casts
  • TRYFREE -> free
  • code style used from upstream to minimize diff
  • defines NOUNCRYPT by default, left it commented in for reference

Sections in need of a careful review:

  • not using MAXU32 in unzip.c
  • usage of static in function definitions (C/C++ difference, implication?)
  • zip.c zipCloseFileInZipRaw64 available/total bytes change

This will be baking in a feature branch for a while, reviews welcome.

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

No branches or pull requests

2 participants