------------------------------ On Sun, Apr 14, 2013 22:34 BST Vincent Povirk wrote:
considering how old zlib is and the vast number of windows application which uses zlib
Given how many people duplicate the effort to package zlib, the fact that they're rarely updated, and the sort of problems gnulib exists to work around, it would not surprise me if your particular zlib binary is broken somehow.
got nobody else to blame - because of exactly the issue you outlined encountered in the past, i am building the application with a private copy of the source of zlib 1.2.7.
Well, here's a simple thing you can check: Does your zlib dll link to _lseek or _lseeki64? The first one uses a 32-bit offset. Wine's implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090) expands that to 64-bit and later truncates the file offset to 32-bit. For a file larger than 2 GB, that could account for the large negative value you're seeing.
And since this would only matter in cases where zlib uses lseek (the first time through I guess it wouldn't, as it has to read the whole everything up to the offset you give at least once) and is at least 2 GB into the file, that might also explain why it doesn't fail initially.
But without really digging into the zlib code, all I can do it speculate.
I should probably also check coapp's build of zlib sometime.
-
Hin-Tak Leung -
Vincent Povirk