First off, thank you for releasing the original source code. I was trying to compile this code, and found some memory errors regarding the HQR uncompressing methods. These methods receive a pointer which is assumed to have enough space to hold both the compressed and uncompressed data. This is achieved by adding some empty space to several prereserved global arrays which will load their data from compressed files. However, that is just a quick patch and some arrays are too small, which renders a memory error. The one that i found is in the file "HQ_RESS.C" line 132, but it is a common issue found all along this library (or along several global arrays). The method that loads the "Adeline logo" data writes directly to the "Screen" global array (640*480 +500 bytes), and after reading the uncompressed data the program "should end" (i found this error running Valgrind memcheck, it actually runs in a normal environment ). The code shows as follows:
line HQ_RESS.C:131
case 1: /* LZS /
ptrdecomp = (UBYTE)ptrdest + header.SizeFile - header.CompressedSizeFile + RECOVER_AREA ;
Read( handle, ptrdecomp, header.CompressedSizeFile ) ;
Expand( ptrdecomp, ptrdest, header.SizeFile ) ;
break ;
- ptrdest is a pointer to some previously reserved memory (the programmer should know the uncompressed size of the data before calling this method).
- ptrdecomp should be a pointer to a memory area of "header.CompressedSizeFile" bytes, but it uses the same ptrdest to save some memory.
The solution is to create an auxiliar pointer, load the compressed data, and call "expand" to uncompress it (assuming ptrdecomp has enough space).
case 1: /* LZS /
ptrdecomp = (UBYTE) Malloc(header.CompressedSizeFile ) ;
Read( handle, ptrdecomp, header.CompressedSizeFile ) ;
Expand( ptrdecomp, ptrdest, header.SizeFile ) ;
Free(ptrdecomp);
break ;
That error is spreaded along the HQ_RESS.c file on some other methods that calls "Expand". Also that should save some memory on several global arrays that don't need that extra space.
I'm not sure if i should make a patch for this code, as it is "legacy". But i think it should be documented somewhere. I was rewritting several parts in order to make a more portable code based on the original sources, so i'll try to check all the memory leaks/errors I find.
First off, thank you for releasing the original source code. I was trying to compile this code, and found some memory errors regarding the HQR uncompressing methods. These methods receive a pointer which is assumed to have enough space to hold both the compressed and uncompressed data. This is achieved by adding some empty space to several prereserved global arrays which will load their data from compressed files. However, that is just a quick patch and some arrays are too small, which renders a memory error. The one that i found is in the file "HQ_RESS.C" line 132, but it is a common issue found all along this library (or along several global arrays). The method that loads the "Adeline logo" data writes directly to the "Screen" global array (640*480 +500 bytes), and after reading the uncompressed data the program "should end" (i found this error running Valgrind memcheck, it actually runs in a normal environment ). The code shows as follows:
line HQ_RESS.C:131
case 1: /* LZS /
ptrdecomp = (UBYTE)ptrdest + header.SizeFile - header.CompressedSizeFile + RECOVER_AREA ;
Read( handle, ptrdecomp, header.CompressedSizeFile ) ;
Expand( ptrdecomp, ptrdest, header.SizeFile ) ;
break ;
The solution is to create an auxiliar pointer, load the compressed data, and call "expand" to uncompress it (assuming ptrdecomp has enough space).
case 1: /* LZS /
ptrdecomp = (UBYTE) Malloc(header.CompressedSizeFile ) ;
Read( handle, ptrdecomp, header.CompressedSizeFile ) ;
Expand( ptrdecomp, ptrdest, header.SizeFile ) ;
Free(ptrdecomp);
break ;
That error is spreaded along the HQ_RESS.c file on some other methods that calls "Expand". Also that should save some memory on several global arrays that don't need that extra space.
I'm not sure if i should make a patch for this code, as it is "legacy". But i think it should be documented somewhere. I was rewritting several parts in order to make a more portable code based on the original sources, so i'll try to check all the memory leaks/errors I find.