2010.06.17 22:10 "[Tiff] libtiff 4.0 compiler warning on x64 in tif_read.c", by Edward Lam

2010.06.29 18:20 "Re: [Tiff] libtiff 4.0 compiler warning on x64 in tif_read.c", by Edward Lam

PS. I should also point out that there are many MORE such warnings when compiling the tools part of libtiff that I have ignored. We're currently completely clean inside the libtiff library source code itself with respect to 64-bit warnings other than this one.

On Thu, Jun 17, 2010 at 6:10 PM, Edward Lam <edward@sidefx.com> wrote:

tif_read.c(207): warning C4244: '=': conversion from 'tmsize_t' to 'int', possible loss of data

Looking at it, it seems to me that we want "read_ahead" to be tmsize_t instead of int? Similarly, I think TIFFFillStripPartial() should take an tmsize_t instead.

It's rather doubtful, considering the purpose of the variable. Here:

// C4244 warning is more trouble than it's worth
#if defined(_MSC_VER)
#pragma warning(push)
#pragma warning(disable:4244)
#endif

Regardless of whether the warning is "more trouble than it's worth", I think that at least for this case, it is warranted. If you examine the mentioned line, we have a 64-bit variable (tif_scanlinesize) multiplied by 2 and 5000 added to it before being assigned to a 32-bit quantity. Are you arguing that it is invalid in the BigTIFF spec to have a scanline size of greater than 2 GiB?

IMHO, if the truncation is intentional, then we should be explicitly casting to signify that fact, ideally along with a comment as to why truncation is acceptable/correct behaviour. But that's probably a philosophical debate.