2004.02.09 19:48 "Re: [Tiff] Photoshop 8.0 and libtiff", by Bob Friesenhahn

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