Draft: Use InflateLib to add Deflate64 support to ZIP decoding #2806
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.
This is a follow-up to #2325.
A while back we wrote and released microsoft/inflatelib, which allows decompression ("inflation") of Deflate and Deflate64 encoded data with its main purpose being to add Deflate64 support to libarchive. The API of the library is modeled after zlib (specifically after
inflate, notinflateBack) and its implementation is based off the implementation in dotnet'sSystem.IO.Compressionnamespace (though it slowly diverged a little for performance reasons, mainly how allocations are handled).Since InflateLib is still considered "prerelease" (we'll probably finalize the API once the implementation here is settled on), I'm issuing this as a draft PR for now, though if there's no contention, there's nothing that should prevent it from getting merged. I've also set the various "enable" switches in the
CMakeListsandautoconffiles to be off by default for now for this same reason. I've also added a vcpkg manifest to the root of the repo to make my - and hopefully others - lives easier for dependency management. E.g. pass-DCMAKE_TOOLCHAIN_FILE=%VCPKG_ROOT%during CMake initialization. It's my understanding that these files don't need to be in the root of the repo - you just need to pass more arguments to CMake to get things to work correctly - so I can move them if desired. This can also be used to help with dependency management in CI (I know @DHowett had plans for this in the past).The implementation itself is virtually identical to the zlib path, since the two APIs are virtually identical. As such, I've also factored out the encryption handling logic since it's the same for both & added a few comments and extra variables for my own benefit of understanding the operations better.