Recent changes to bugs

Zlib not recognized in OS5

Anonymous — Wed, 15 Jan 2003 20:06:58 -0000

Zlib is not recognized in OS 5 (Tungsten). Using
Plucker, when opening documents, screen Zlib not
supported: "This device cannot handle Zlib compressed
documents". Comes up and it does not find document.
Used Zlib distribution with Plucker, and then 1.1.3-7
from your website, same results. Zlib is installed.
However, when viewing version, it shows version 0.0.
I need compiled Zlib for OS5, as I am not a Palm
developer.

Theys Radmann
theys.radmann@radmann.cl

ZLibcompr function always returns me buf

Anonymous — Sat, 10 Aug 2002 08:47:38 -0000

Following are the snap of the code.

if (ZLSetup)
{
char dest[100];
char result[100];
uLongf destLen = 100;

char source[] = "a string to compress";
int err;
uLongf sourceLen = strlen(source) + 1;

err = ZLibcompress2(ZLibRef, (Bytef *)dest, &destLen,
(Bytef *)source,
sourceLen, Z_DEFAULT_COMPRESSION);

ULong lUncompLen = 100;
err = ZLibuncompress(ZLibRef,(Bytef *)result,
&lUncompLen,
(const Bytef *)dest, destLen);
}

but ZLibcompress2 always returns Z_BUF_ERROR
regardless of the destination
buffer size.

misuse of static variable in library cod

Semenov — Fri, 01 Mar 2002 05:21:53 -0000

Hi!

When I went through the source code, I found a lot of
misuse of static variables, in face according to rules
for library building, one must not use static
variables in the library source code.
Somehow it works with gcc, but I guess it hides some
bugs, that use this space, but when it come to
CodeWarrior it starts crashing.
I propose to pass all static variables as a structure
set thru TableEntry variable which can be accessed by
SysLibTblEntry(LibRef), that doesn't require locking
the table variable. The same way it can be accessed in
the library code.

struct constants
{
char *data1 = ...
char *data2 = ...
bool data3 = ...
char *data4 = ...
....
}

struct constants const_data;
const_data.data1 = table1
const_data.data2 = ....
...
SysLibTblEntryPtr libEntryP = SysLibTblEntry(libRef);
libEntryP->globalsP = (void*) &const_data;

in the libarary you can use:

((struct constants*)SysLibTblEntry(libRef))->data1;

That's it

Best Regards
Dmytry

deflateInit() memory allocation problem

Anonymous — Wed, 30 May 2001 23:10:06 -0000

Calling deflateInit() on machines with only 2Meg of
memory, results in a fatal error or other hard crash.
Depending on device, it looks like the screen memory
mapped area is getting over written with zero's.

Providing my own Alloc and Free functions prior to the
deflateInit() call, where myAlloc() raises a
SystemFatalException if it runs out of memory (the
suspected root cause), shows that the allocated
request for compression are about twice as I expected
to see from the provided documentation. The memory
requirements for decompression looked as expected.

E.G - decompression resulted in the following myAlloc
() calls:
item, size
1, 18
1, 52
4,1440
1,8192
296,2
19,2
288,2
1,20

However, the compression side looks goofy to me:
item, size
1, 4595
8192, 2
8192, 2
8192, 2
4096, 4
3, 14

For a total allocated request of 68K !!! Was expecting
a 38K hit.

For small footprint PalmOS devices, they run out of
memory room in my application during the third 8192x2
alloc().

Eh, shouldn't the size requests for the 8192 and 4096
items be 1 byte and *not* 2 bytes each?

I'm guessing that the default memory allocation
function gets back a null pointer and then uses it in
the following zmemset(), giving the reported error.

Error when mem alloc fails in calloc

Dave Morehouse — Tue, 01 May 2001 21:22:44 -0000

When the function calloc is called (When running on
the Palm OS) if not enough memory is available then
NULL is returned. Then when setting the memory at
address NULL to zero the palm throws up a system error
message stating that you must reset the device.
Here's the original code and two possible ways to fix
it.

voidpf zcalloc (opaque, items, size)
voidpf opaque;
unsigned items;
unsigned size;
{
#ifndef PALMOS
if (opaque) items += size - size; /* make compiler
happy */
return (voidpf)calloc(items, size);
#else
voidpf x;
UInt32 free, max;

x = (voidpf) malloc(items*size);
zmemzero(x,items*size); // This is where it fails
return x;
#endif
}

New version mod 1

x = (voidpf) malloc(items*size);
if(x != Z_NULL) // This stops it from crashing
zmemzero(x,items*size);
return x;
#endif
}

New mod using Palm OS Specific stuff

x = (voidpf) malloc(items*size);

if(x == Z_NULL)
{
MemHeapFreeBytes(0, &free, &max);
if(items*size > max)
MemHeapCompact(0);
MemHeapFreeBytes(0, &free, &max);
if(max >= size)
x = (voidpf) malloc(items*size);
}
if(x != Z_NULL)
zmemzero(x,items*size);
return x;
#endif
}

This version checks to see if the allocation can work
after compacting the heap

Last fix number 3

extern inline void zmemzero OF((Bytef* dst, uInt num))
{
if(dst == NULL) // added these two lines
return; // which also fixes the problem
while (num--)
*((char *) dst)++ = 0;
}

Hope this helps