On Friday, September 10, 2010 at 6:53:48 PM UTC+5:30, Slaunger wrote:
Although I am just having a dialogue with myself here, I finally
figured out what the problem is:-) (I cannot solve my problem, but now
I at least know what it is)
The lzo python bindings does not return the exact same array of bytes
as the C-library functions. They add a header, where the first byte is
0xF= for LZO-1X compr lvl 1, and then an uint 32 representing the
number of bytes in the *uncompressed* byet array. Apparently, this convenience information is used in the Python binding uncompress
function, to allocate the right sized buffer for the output prior to
calling the lzo library uncompress function. Really crap binding code
if you ask me as it measn that I have to know *in advance* how many
bytes a compressed array of bytes will unpack into *prior* to calling lzo.uncompress. And if it is compressed data from another data source,
it is really not possible to know that final data size beforehand,
which is...crap.
Just use lzo.decompress(data,False,out_len,alogrithm="XYZ")
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)