LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.03.02 18:13 "Re: Patch for tif_unix.c", by Edward Lam
Eric Doenges wrote:
> 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