1994.08.08 09:38 "minor(?) problems with libtiff", by Soren Pingel Dalsgaard

1994.08.08 09:38 "minor(?) problems with libtiff", by Soren Pingel Dalsgaard

So far I have not mad any problems with the libtiffw library which originated from the 002 beta of libtiff. But now I have given it another check. The Microsoft compiler gives me some warnings which I used to ignore. But yesterday I thought I had better check them out.

And the warnings actually points at potential problems. Especially when dealing with large tiff files.

The tiff library lets each platform specify its own way to do memory allocation and file handling. But the allocated memory is being treated by memset, memcpy and memcmp functions without thinking that there might be a problem with pointers. I think these memory functions should be moved to the platform specific files as well.

The main problem involved in using memcpy, memcmp and memset is that size_t and long/u_long are mixed through the program. On unix machines size_t may very well be a long/u_long (32bit), but in Windows 3.x the size_t is only a 16bit thingybob. Therefore:

  { long cc;
    cc = 123456L;

is a *BAD* thing in Windows. It can be done, either with a loop, or with hand coded assembler, but something has to be done. How to approach this problem?

Should we make platform specific _TIFFmemcpy, _TIFFmemcmp and _TIFFmemset functions that uses u_long instead of size_t as the size parameter?


is related to pointers. Memory allocated throught _TIFFmalloc is now simply a void*. It used to be tdata_t. Why this has changed, I don't know. Large memory chunks allocated in Windows 3.x must be 'void huge*' to make sure that they can access more than 64K (one segment of data). This was possible before that change to void*. Maybe we could introduce a talloc_t type to be memory allocated by _TIFFmalloc.

I know that this is a problem, but many people would really like the LibTIFF library to work in Windows, and until these issues have been dealt with, I don't think it will be possible.

Maybe we could just sit down and wait for Windows NT and Windows 4.0 to be installed everywhere Windows 3.x is now. Maybe we could solve the problem.


X.,Soren Pingel Dalsgaard, Computer Science Department  )\._..--....,---,
P';Aarhus University, Ny Munkegade 116, DK-8000 Aarhus /,   _.. \   _.. ,`._ ,.
\ |DENMARK, email:pingel@daimi.aau.dk, ph:+45 89423284`._.-(___.'..(___.'`-.;.'