Boost logo

Boost :

From: George M. Garner Jr. (gmgarner_at_[hidden])
Date: 2004-09-11 15:44:17


> Dumb question - is Winzip supposed to be able to read the zlib format? I
> usually
> use it to decompress .zip or tar.gz archives. <

Well I made that assumption because Winzip and XP both maintain associations
for the .z extension. This is from the Winzip help file:

> Since almost all new archives are created in Zip format, WinZip does not
> provide
> facilities to add to or create files in these formats (however, all other
> WinZip
> functions are supported). <

 In the code that I included in my previous post I see that I am using a zip
extension. But I tried it both ways to no avail.

> I hate these stupid lowercase macros!<

Yes. It is very bad coding style. I grepped for in in your library, boost
and bzip and couldn't find who was defining it. :-(

>> bool eof = (state_ & f_eof) != 0;
>> if (buf_.ptr() != buf_.end() || eof) {
>> bool done =
>> !filter_->filter(
>> const_cast<const char_type*&>(buf_.ptr()),
>> buf_.end(), next_s, end_s, eof
>> --) && eof;
>> ++) || eof;
> Thanks. It took me a long time to get this to work with my sample data,
> but
> since I tried only a few samples, I guess I'm not surprised it's still
> wrong.
> Somehow, though, I seem to remember "|| eof" failing, too.

You're welcome to the sample project if you like. The problem is that, with
the bzip2 sample, eof is reached and next_s != end_s. That may be a bug in
itself however I don't think that you can rely on this condition always
being true at eof. You also would enter the infinite loop by trying to read
a malformed zlib or gzip archive, for example. When eof is reached you have
to be "done."

> BTW, I just now realized that you're the one I was discussing these issues
> with
> over at ;-)




Boost list run by bdawes at, gregod at, cpdaniel at, john at