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
I can’t really offer much in terms of suggestions; I wasn’t able to get the code you sent to work… there’s something wrong with the zip string. I can say that the zlib that I used is both a) old and b) has been used for previous pike builds (thought probably not recently). Seems odd that the lib would be at fault, but what do I know?
Bill
On Jul 26, 2014, at 4:51 PM, Chris Angelico rosuav@gmail.com wrote:
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
On Tue, Jul 29, 2014 at 11:04 AM, H. William Welliver III bill@welliver.org wrote:
I can’t really offer much in terms of suggestions; I wasn’t able to get the code you sent to work… there’s something wrong with the zip string. I can say that the zlib that I used is both a) old and b) has been used for previous pike builds (thought probably not recently). Seems odd that the lib would be at fault, but what do I know?
Yeah, I had no problems with 7.8.700, but once my users started upgrading to 866, I saw problems. It's really odd.
ChrisA
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
H. William Welliver III