Johnathan,
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 microsoft.public.vc.stl ;-)
Busted. Regards, George.