Received: by cthulhu.engr.sgi.com (940707.SGI.8.6.9/911001.SGI)
	for tiff-list id IAA02132; Mon, 8 Aug 1994 08:25:29 -0700
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (940707.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id IAA02126; Mon, 8 Aug 1994 08:25:25 -0700
Received: from relay.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.sgi.com> id IAA05675; Mon, 8 Aug 1994 08:25:22 -0700
Received: from oxford.chez.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA00237; Mon, 8 Aug 94 08:25:20 -0700
Received: by oxford.chez.sgi.com via SMTP (931110.SGI/930416.SGI)
	for tiff@sgi.sgi.com id AA27904; Mon, 8 Aug 94 08:32:48 -0700
Message-Id: <9408081532.AA27904@oxford.chez.sgi.com>
To: S|ren Pingel Dalsgaard <pingel@daimi.aau.dk>
Cc: tiff@sgi.sgi.com (Tiff mailing list)
Subject: Re: minor(?) problems with libtiff 
Reply-To: Sam Leffler <sam@asd.sgi.com>
In-Reply-To: Your message of "Mon, 08 Aug 1994 11:38:52 +0700."
             <199408080938.AA06539@angers.daimi.aau.dk> 
Date: Mon, 08 Aug 1994 08:32:47 PDT
From: Sam Leffler <sam@oxford.chez.sgi.com>
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

    To:  tiff@sgi.sgi.com (Tiff mailing list)
    Subject:  minor(?) problems with libtiff
    Date: Mon, 08 Aug 1994 11:38:52 +0700
    From:  S|ren Pingel Dalsgaard <pingel@daimi.aau.dk>

    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



