| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2004.02.09 19:48 "Re: Photoshop 8.0 and libtiff", by Bob FriesenhahnOn Mon, 9 Feb 2004, Frank Warmerdam wrote: > > Bob, > > My first thought was, "hey, we already work fine with 4GB files". But upon > a bit of review I realize we use unsigned int for toff_t, but a signed int > for tsize_t. The comments in tiffio.h mention that tsize_t is int32 and not > uint32 because some functions return -1. So, I think that is why uint32 > isn't used now. > > I do kind of wonder if the code could be changed somehow to use uint32 for > tsize_t but recognise 0xffffffff as end-of-file, instead of -1. There > couldn't be something 0xffffffff bytes long in a file of 4GB or less anyways > since there is always some other overhead. I am sure that this change could be accomplished, however, before any steps are taken, the API should be looked at to verify there is any advantage from doing so. 32-bit operating systems commonly reserve 1GB, or 2GB of the process address space for their own use. For example, Windows provides the application with a maximum 2GB of usable address space. This range is handled by the existing signed size type. If the API provides access to the strip via a single memory allocation, then it will certainly be impossible to access more than a 2GB strip on a typical 32-bit OS. A 64-bit application on a 64-bit OS could deal with this just fine except there would be thrashing if there is not enough RAM. Improving the API to support iterative access to a strip would be a superior solution. Then an unsigned 32-bit offset type and a signed 32-bit size type would be more than sufficient. Does this iterative interface already exist? Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us http://www.simplesystems.org/users/bfriesen |
|||||||