[Zlib-devel] zlib 1.2.3.6 available for testing

[Török Edwin]

On 01/18/2010 08:16 PM, Mark Adler wrote:
> On Jan 18, 2010, at 8:06 AM, Török Edwin wrote:
>   
>> This doesn't mention that it can fail due to zlib version mismatch
>>     
>
> Actually that can't happen in the gz* functions, since they are already compiled, using the original library header file.  A version mismatch can occur only if a compiled library is used with a zlib.h file with a different version, which there is only detected for the Init functions.
>   

Yes, and the new gz* implementation doesn't even call deflateInit2, I
was looking at the wrong file.

Now that I am looking at the correct files (gzlib.c, gzread/write.c,
gzclose.c right?) I notice some additional issues:
 - it no longer uses fdopen, so I'm not sure it should be mentioned that
the old one was using it in zlib.h (as I suggested in my previous email)
 - if seeking fails (gzwrite.c:182) in gzclose_w it doesn't close the
file descriptor, I think it should
 - gzclose_w returns Z_ERRNO if close() fails, and gzclose_r doesn't.
Although it is unlikely that closing a readonly descriptor would fail
(unless something else
mistakenly closed zlib's the descriptor already), I think that it should
behave the same as _w for consistency.
 - no error checking for this malloc: state->path = malloc(strlen(path)
+ 1);

Also  perhaps gzclose's documentation should mention that if gzclose
fails you must not call it again on same gzFile since it was
deallocated. If you do call it twice,
it'll just crash, unlike close(2) where the worst that can happen is
that it closes some other thread's descriptor (if the fd was reallocated
meanwhile).


>   
>> There may be more functions where Z_VERSION_ERROR is missing from the docs.
>>     
>
> Only deflateInit, deflateInit2, inflateInit, inflateInit2, and inflateBackInit can return Z_VERSION_ERROR.  In fact, for some reason zlib.h failed to mention this for deflateInit2, so that has been fixed.
>   

Ok, thanks.

Best regards,
--Edwin