kayws426 / fastlz Goto Github PK

It would be nice if fastlz had 64-bit support.  Simply switch all those cursed 
int's to uint64's.

OR, just add 32-bit -AND- 64-bit support via pre-processor options!

http://fastlz.org/download.htm
the link to this:
https://code.google.com/p/fastlz/downloads/list
seems off/wrong

On sunsparc64 machine, the function fastlz2_compress() for FastLZ level 2
results in SEGV while accessing invalid memory pointed by ip in
HASH_FUNCTION at line 376. 

This happens only when the input data pattern encounters 5-byte match as
given below and distance is greater than 1 indicating it's not a run. The
for loop given below makes an assumption that the ip_limit condition
restricts ip to be atleast 8 less than ip_bound value. But when we find
5-byte match, the ip value may exceed ip_bound value. This results in
accessing invalid memory within HASH_FUNCTION.

What steps will reproduce the problem?
1. Compile the code with high warning level.

Those warnings could be avoided by using the proper casts 

   *op = static_cast<flzuint8>(..)

Thank you.

What steps will reproduce the problem?
1. Call compress with 64K chunks.
2. Running on a 64bit machine.

What is the expected output? What do you see instead?
hslot is NULL I get a segfault on the *hslot=ip line.

What version of the product are you using? On what operating system?
latest trunk

I am getting the following warnings:

1>fastlz.c(234) : warning C4244: '=' : conversion from '__int64' to
'flzuint32', possible loss of data
1>fastlz.c(304) : warning C4244: '=' : conversion from '__int64' to
'flzuint32', possible loss of data
1>fastlz.c(417) : warning C4244: 'return' : conversion from '__int64' to
'int', possible loss of data
1>fastlz.c(548) : warning C4244: 'return' : conversion from '__int64' to
'int', possible loss of data
1>fastlz.c(234) : warning C4244: '=' : conversion from '__int64' to
'flzuint32', possible loss of data
1>fastlz.c(304) : warning C4244: '=' : conversion from '__int64' to
'flzuint32', possible loss of data
1>fastlz.c(417) : warning C4244: 'return' : conversion from '__int64' to
'int', possible loss of data
1>fastlz.c(548) : warning C4244: 'return' : conversion from '__int64' to
'int', possible loss of data

It would be nice if these warnings could be tidied up by casting the
datatypes as necessary.

- Simon.

On a sun4u machine compile with gcc version 4

sunw389:fastlz>gcc 6pack.c fastlz.c -o 6pack -g
sunw389:fastlz>gdb 6pack
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run 6pack 6pack.6p

Program received signal SIGSEGV, Segmentation fault.
0x000120d0 in fastlz2_compress (input=0xffbdec10, length=34332,
output=0xffb9ec10) at fastlz.c:199
199         HASH_FUNCTION(hval,ip);
(gdb)


Using Sun studio 11 cc without -fast option works.

On a sun4u machine compile with gcc version 4

sunw389:fastlz>gcc 6pack.c fastlz.c -o 6pack -g
sunw389:fastlz>gdb 6pack
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run 6pack 6pack.6p

Program received signal SIGSEGV, Segmentation fault.
0x000120d0 in fastlz2_compress (input=0xffbdec10, length=34332,
output=0xffb9ec10) at fastlz.c:199
199         HASH_FUNCTION(hval,ip);
(gdb)


Using Sun studio 11 cc without -fast option works.

Got misaligned data access at this line in FASTLZ_DECOMPRESSOR:

          *q++ = *p++;

I replaced all of 
        /* copy a byte, so that now it's word aligned */
        if(len & 1)
        {
          *op++ = *ref++;
          len--;
        }

        /* copy 16-bit at once */
        q = (flzuint16*) op;
        op += len;
        p = (const flzuint16*) ref;
        for(len>>=1; len > 4; len-=4)
        {
          *q++ = *p++;
          *q++ = *p++;
          *q++ = *p++;
          *q++ = *p++;
        }
        for(; len; --len)
          *q++ = *p++;

with
      while(len--) *op++= *ref++;

and now it works fine (and fast I think).

Hi,

The following program makes FastLZ read past the end of its input, possibly 
causing a crash:

#include <string.h>
#include <stdlib.h>
#include "fastlz.h"

int main(int argc, char** argv)
{
        char out[4096];
        char *in = (char *)malloc(6);
        in[0] = 0x23;
        in[1] = 0x00;
        in[2] = 0x00;
        in[3] = 0x00;
        in[4] = 0x00;
        in[5] = 0x40;

        return fastlz_decompress(in, 6, out, 4096);
}

You can verify the read-past-end behavior with Valgrind or similar.