Closed skalleAnka closed 1 year ago
Maybe you can submit a PR.
If I did submit one, the change I would make is to revert all changes on this line to before these two changes. This is because I have no knowledge of why this casting was added in the first place, seems pretty unnecessary to me.
But I assume it was put there to either silence a warning on some compiler that I don't have or fix some remark by some code analysis tool that I probably also don't have. So I wouldn't know what the proper fix is.
This issue causes zip files over 2GB created via Minizip to be unreadable by other programs. I have opened a PR to fix it: #790
@gvollant: Can you look?
Faced the same problem. Maybe replace z_off_t with z_off64_t in fseek64_file_func? Correctly worked in VC14.3 and GCC9.4
Already addressed by #749.
If I did submit one, the change I would make is to revert all changes on this line to before these two changes. This is because I have no knowledge of why this casting was added in the first place, seems pretty unnecessary to me.
It was to silence a warning for the implicit casting of an unsigned type to a signed type. This is now addressed by https://github.com/madler/zlib/commit/05527a1b1ef39014b44281fbbbec5deabb4be106 .
In commit 2014a993addbc8f1b9785d97f55fd189792c2f78, ioapi.c funcion fseek64_file_func was changed to cast the offset to a long, truncating the 64 bit offset value.
This was changed in commit 9b291c9f013f99ad494ffecf4295cb2f594a18e3 to be a z_off_t.
If you build minizip on Windows with Visual C++ without defining z_off_t yourself, zconf.h will define it as a long, which still causes truncation.