stargus 2.2.5.5 not compiling on on OpenBSD 5.0 GENERIC.MP#59 i386 - patches included

[timfel]

-patch files attached

-stargus 2.2.5.5 not compiling - compile options need to be updated in Makefile

-zlib header file needs to be included

-removed need to worry about letter case for list files

-huffmann decompression segfaulting - bug fix uses modified code from stormlib; original stormlib code was also segfaulting; original macro code PTR_VALID, PTR_INVALID, PTR_INVALID_OR_NULL assume all addresses are above 0x80000000 or all are below; segfaults when addresses are above and below 0x80000000; only need to check for two invalid addresses - updated macro code

-libpng code needs to be upgraded to 1.5.4

---

Imported from Launchpad using lp2gh.

• date created: 2011-12-31T00:25:39Z
• owner: emtneutrino
• assignee: pali
• the launchpad url was https://bugs.launchpad.net/bugs/910269

[timfel]

(by emtneutrino)

[timfel]

(by pali) Thanks for patches! Can you rebase patches on branch https://code.launchpad.net/~pali/stargus/64bit ? Here is fixed some problems on 64bit systesm.

[timfel]

(by emtneutrino) Attached are my patches for the 64 bit branch

[timfel]

(by pali) Can you also send patch which fixing StormLib crashing to StormLib maintainer?

[timfel]

(by emtneutrino) done!! I included you in the email.

[timfel]

(by pali) Now 64bit support in Stargus is complete and patches commited.

[timfel]

(by emtneutrino) This is an email I sent to the creator of StormLib explaining why I had so many segfaults on my machine using its Huffmann source code. The huff.cpp and huff.h files I submitted to this project are still correct.

Subject: Re: Re[2]: patches for huffmann decompression routines in StormLib From: electronmuontau neutrino To: Ladislav Zezula

I was mistaken about the reason behind my machine segfaulting frequently when using the original version 2.01 of the Huffmann source code from StormLib. The real reason my machine would segfault so often is because mul is declared static. It is initially set to +1 and is never set to +1 anywhere else. The THuffmannTree constructor sets mul to -1 when "this" < 0, but it never sets mul to +1 when "this" > 0. Once mul is set to -1, it ALWAYS stays -1 even if a new instance of "this" > 0. In the case where mul = -1 and "this" > 0, the PTR_VALID macro will be wrong about an invalid address and lead to a segfault. The same is true for PTR_INVALID and PTR_INVALID_OR_NULL. If it is guaranteed that ALL valid addresses will have one sign, and ALL invalid addresses will have the opposite sign, the THuffmannTree constructor should set mul to +1 when "this" > 0 and set mul to -1 when "this" < 0. There is no way to guarantee this, however. This DOES NOT WORK when valid addresses have a mixture of POSITIVE AND NEGATIVE signs. In this case, it is impossible to determine a valid address from an invalid address.

Here is an example where PTR_VALID fails and causes a segfault:

define PTR_NOT(ptr) (THTreeItem *)(~(DWORD_PTR)(ptr))

define PTR_VALID(ptr) (((LONG_PTR) (ptr) * mul > 0)

address of "this" = 0x8000182A = -2147477462 <---- Assume this is a valid address. Its sign is negative, therefore mul = -1 address of pFirst = 0x7FFFE7D6 = 2147477462 <---- Assume this is a valid address. Its sign is positive

PTR_NOT(pFirst) = 0x80001829 = -2147477463 <---- This should be an invalid address since pFirst is valid

When any code uses the PTR_VALID macro for pFirst and PTR_NOT(pFirst) with the addresses above, PTR_VALID(pFirst) = 0 <---- This means that pFirst is invalid which is not true PTR_VALID((PTR_NOT(pFirst)) = 1 <---- This means that PTR_NOT(pFirst) is valid which is also not true and will lead to a segfault

Note that 0x7FFFE7D6 + 0x00003054 = 0x8000182A in this case.

My patches DON'T depend on the sign of any addresses. The version of the files huff.cpp and huff.h that I created patches for is 2.01 at http://zezula.net/en/mpq/download.html#StormLib.

I hope this clears up any confusion. Neil