2010.03.02 18:13 "Re: [Tiff] Patch for tif_unix.c", by Edward Lam

If tmsize_t can be guaranteed to be identical to ssize_t, then no check is necessary (as long as we can assume there are no systems where SSIZE_MAX is smaller than what would physically fit into a ssize_t). If not, then the "(size_t)size == (tmsize_t)size" check won't necessarily help us as the read()/write() functions have undefined behaviour when attempting to read/write more than SSIZE_MAX bytes.

However, if tmsize_t is just a libtiff equivalent to ssize_t, then the "(size_t)size == (tmsize_t)size" isn't necessary either, since the condition should always be true (unless a negative size is requested, which doesn't make any sense for I/O operations). I had assumed the check was necessary because tmsize_t might be bigger than {s}size_t, and thus didn't think I could use tmsize_t instead of ssize_t. Perhaps whoever wrote the current form of the _tiff{Read,Write}Proc() functions could chime in as to what was intended?

If tmsize_t was bigger than ssize_t, then woudn't we already have a bug in the original code? In practice, coding errors could potentially cause us to get negative size values so this could be just defensive coding?

Bob Friesenhahn committed revision 1.18 of tif_unix.c where we used to have a loop that ensured that we never wrong more than SSIZE_MAX bytes at a time. So, Bob? :)

Regards,

-Edward