LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 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.06.29 18:20 "Re: 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. Edward Lam wrote: > Albert Cahalan wrote: >> 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. > > Regards, > -Edward > >