1994.08.08 15:32 "Re: minor(?) problems with libtiff", by Sam Leffler

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 code basically follows ANSI C/POSIX conventions. I know of nothing in these specs that tries to address 16-bit klunkers :-).

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;
    memcpy(dst,src,cc);
  }

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?

Some places are explicitly long or u_long because the potential size of the memory region *can* exceed a 16-bit quantity. At least, that's what I tried to do. I wouldn't be suprised if there were other places where size_t was not used because of carelessness. size_t is certainly not well followed under most UNIX systems because virtually all are 32-bit based.

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

I would prefer to encapsulate the memory management functions more carefully. I will take a look at the IJG code.

ANOTHER PROBLEM

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.

Changed from what? As far as I can recall it's always been void* or similar.

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.

If you provide me with diffs against v3.3beta015 then I will work with you to incorporate them into the code. I am however leery of all these 16-bit issues. There are significant changes pending to the library and I can not vouch for future versions working under Windows or similar 16-bit systems (I simply don't use such systems and so have no way to test anything). Of course if you were to work more closely with me then 16-bit support would presumably not be an issue.

        Sam