Not sure how to diagnose this. Test case:
int main()
{
string
zip="E\217Aj\3""1\fE\367s\212OV-\204\\\243\27\310\276(cMF\240X\306\226;8\247\217fh\323\225\340\363y\377\351\272JC\222\312\263[\35\230)\343\306\350\215\23\26\253P\233IQ\264\337%\267""3\266U\346\25T\31\331\34\205\252\303\26\370\312x\220\344\351k\224\326\37\250\\\254\311\316\273\340\272\362\300&\252;V\215R\200iq\256
}\203!\371\r\371\313\246\177\251\217\324\31nQ\t\327\33K\276\207\247j\220N\317\347\367\241x\2\345\24\205\336\320\254\372^Qj\376y\336\363\351\330\317\374\23\253aaq\267*\356\34\277\216(\f\364\222\310\217\215\337\27\304\33\353r\231^";
object infl=Gz.inflate(-15);
string data=infl->inflate(zip);
write("Inflated %d bytes to %d; end-of-stream ought to be \"\":
%O\n",sizeof(zip),sizeof(data),infl->end_of_stream());
}
Yeah, that's hardly minimal, sorry. It does seem to be data-dependent.
On Pike 8.0 on Linux, this produces:
Inflated 185 bytes to 287; end-of-stream ought to be "": ""
This is correct. The given byte stream is a complete deflation
sequence, and end-of-stream is reached with no additional data. Pike
7.8.866 on Windows (the current .msi) says 0 at the end, instead -
implying that it's still looking for more data.
I'm no expert on compression algorithms, so I have no idea what's
going on here. Is it some kind of weird bug in zlib?
ChrisA
