🚀 go-pugleaf

sam wrote:

Oh dear, out of the frying pan into the fire.

The reason AnsiString is not well suited to storing binary data is
because binary data often contains NULLs ('\0' and/or L'\0'). These are
the string termination character. AnsiString keeps track of its length
separately using a variable so for the most part it can store strings
with embedded NULLs. You have to be very careful when doing this and
it's a bit of an abuse of the class but with care it will work.

What you have done is get rid of AnsiString (which copes passably well
with binary data) and replace it with a 'char *'/strlen() combination
and that is going to cause you problems.

You seem to be under the illusion that when you compress a string what
you get out is a string. Wrong! When you compress a string what you get
out is binary data and it should be handled as such.

Calling strlen() on 500 bytes of binary data could return /anything/.
It could even run off the end and either trigger an AV or report a
length of several megabytes. This is C/C++ string handling 101.

Your original decompression code returned the error Z_BUF_ERROR. If you
read the header for zlib you will see (as I tried to point out) that
this means "I can't fit any more data into the output buffer".

Hence my advice to you to check the calculation:

 ulBuffLen = sString.Length() + pMaxBuffer+12;

The three elements on the right hand side all look suspicious to me.

'sString.Length()'
Why should the amount of data you get from decompression be directly
related to the length of the compressed data? Compression ratios vary
from 1:1 (no compression) to 100:1 (10 bytes in means 1000 bytes out).
I find it very odd that this term would appear within this calculation.

'pMaxBuffer'
This looks like hungarian notation but as such would mean it was a
pointer. Obviously (I hope) using a memory address in a calculation to
determine a length should appear odd to anyone.

'+12'
Numeric literals should automatically be treated with suspicion. 'nuff
said.

You need to either determine the maximum possible output from
decompression like we do (we know that the compressor works in 32kB
chunks so that we will always get 32kB out of the decompressor) or else
make a note of the original length and pass it to the decompressor.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html