Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes: > You have added contrib/bzip2-pipe.patch. Could you describe why > this patch is needed and how likely it is to break other programs > that use libbz2?
I found this in <file://localhost/usr/share/doc/bzip2/manual.html#bzread>: # BZ2_bzRead will supply len bytes, unless the logical stream end # is detected or an error occurs. Because of this, it is possible # to detect the stream end by observing when the number of bytes # returned is less than the number requested. Nevertheless, this # is regarded as inadvisable; you should instead check bzerror # after every call and watch out for BZ_STREAM_END. I think your patch makes BZ2_bzRead violate this specification. So if this patch is added to bzip2, the manual will have to be changed as well. I'm not sure there would be a compatibility problem though. The different behaviour seems to be restricted to situations where fread reads some data but not as much as requested, and the bzip2 data that was read contains neither corruption nor an end-of-stream marker. Then: - bzip2-1.0.3 sets error BZ_UNEXPECTED_EOF and returns 0. - The patched version returns the number of bytes decoded, and can decode more in later calls. The idea being that if the FILE being read is a non-blocking pipe, then the application can wait with select() until more data has arrived, and then call BZ2_bzRead again. If the FILE being read is a blocking regular file that is not growing, and the bzip2 data in it is complete or corrupt, the calling application sees no difference between bzip2-1.0.3 and the patched version. If the FILE being read is a blocking regular file that is not growing, and the bzip2 data in it is incomplete, the calling application can get first (BZ_OK, size) where size<len, and then (BZ_UNEXPECTED_EOF, 0) in the next call. There is a risk that an application might look at just the BZ_OK and assume that size==len; then it would read uninitialized data from the buffer. However, because of the BZ_UNEXPECTED_EOF from the next call, it seems likely that the result will be thrown out anyway. If the FILE being read is a non-blocking pipe or socket or character device, then the BZ2_bzRead of bzip2-1.0.3 cannot handle it, so applications probably don't use it for that. If I maintained bzip2, I think I would not apply this patch, because it risks breaking some applications that use libbz2 as advised in the manual. However, a new BZ2_bzRead2 with these semantics could be possible; then ELinks could detect whether this function is present. Another alternative would be to make ELinks skip BZ2_bzRead and related functions and instead use the low-level BZ2_bzDecompress directly.
pgp2anjA9VBQR.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
