Boost logo

Boost Users :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-10-31 13:04:51


Tiago de Paula Peixoto wrote:
> On 10/30/2005 10:34 PM, Jonathan Turkanis wrote:

> > gzip_compressor works as follows: The first time you write data to it, it
writes
> > the gzip header information to the downstream Sink, and then writes the
> > beginning of the compressed data. When the filter is closed, it writes any
> > compressed data that has been buffered, plus the gzip footer, which consists
of
> > a checksum and the length of the uncompressed data.
> >
> > In the above example, the filter is automatically closed at the end of main;
> > this causes the gzip footer to be written. But since no data was ever
> > compressed, the gzip header has never been written.
> >
> > I guess this is a bug of some sort. What behavior would you expect in this
> > case? It seems to me it would make the most sense to output data in the gzip
> > format representing a 0-length file.
> >
>
> That would also make sense to me, but it would be inconsistent with the
> bzip2_compressor behavior, which doesn't write any footer if there was
> no header.

I can't really change the behavior of bzip2, since it's just a wrapper around
libbz2, whereas with gzip I implemented the header and footers myself. I
wouldn't worry too much about consistency, since this is a corner case.

> And also it would create an impossibility of just visiting a file in
> append mode, without writing any data to it.

I don't follow. What do you want to be able to do?

> This could be fixed if
> gzip_compressor were seekable. Is this possible to be implemented?

The only way I can see to implement this would be to buffer all i/o and only
compress or decompress it when the stream is closed. This could be implemented
as an adapter that would work with almost any filter, so I wouldn't want to
build it into gzip. I'll put this on my list of possibilities for 1.34.

> Is
> this an intended feature?

-- 
Jonathan Turkanis
www.kangaroologic.com

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net