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

Can I simply assume that SSIZE_MAX will be defined in <limits.h>, and that <limits.h> will be available for all platforms that matter to libtiff ?

If Visual Studio has SSIZE_MAX in <limits.h>, then it probably will be. :)

As for the patch, I alluded earlier (poorly?) that ssize_t is not available on all platforms. Specifically, it's not available on Windows. Despite it's name, tif_unix.c has been known to be used on Windows by people. Looking at the source in some detail now, tmsize_t looks to be the cross-platform signed equivalent to size_t in libtiff. Note also that _tiff{Read,Write}Proc() already tries to carefully ensure that "(size_t)size == (tmsize_t)size". Given this, I suspect that your extra checks with SSIZE_MAX are probably unnecessary?

I've probably missed something but I think the original patch was sufficient (EINTR issues notwithstanding) as long as "bytes" was declared as a tmsize_t?

What is the correct response to receiving EINTR (i.e. being interrupted before any data is read/written) ? Should the IO operation simply be retried in _tiffReadProc/_tiffWriteProc, or should the caller handle it ?

To me, this is a thorny issue. On Windows, signals don't exist so you can't exactly check for EINTR. Two ideas off the top of my head:

Continue punting. We've lasted this long without it. :) One rationale is to force users to use SA_RESTART with sigaction. Of course it doesn't help you if you're on one of those systems that don't support this. In which case, the caller needs to revert back to providing their own custom handlers again. Does your particular system support SA_RESTART?
Wrap the read()/write() calls using the TEMP_FAILURE_RETRY() macro and configure it properly depending on the platform. (See: http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html#Interrupted-Primitives)

Regards,

-Edward