On 4/8/2013 5:41 AM, Richard Hipp wrote:
Line 6766 u.bc.r.flags = (u16)(UNPACKED_INCRKEY * (1 & (u.bc.oc -
OP_SeekLt))); WARNING: conversion from 'u16' to 'u8', possible
loss of data
Line 71133 iBuf = p->iReadOff % p->nBuffer;
WARNING: conversion from 'i64' to 'int', possible loss of data
Line 71209 iBuf = p->iReadOff % p->nBuffer;
WARNING: conversion from 'i64' to 'int', possible loss of data
Line 71286 iBuf = iStart % nBuf;
WARNING: conversion from 'i64' to 'int', possible loss of data
Line 71574 p->iBufEnd = p->iBufStart = (iStart % nBuf); WARNING:
conversion from 'i64' to 'int', possible loss of data
The first warning is harmless and results from a prior datatype change.
Dan has already fixed that one. The other four appear to be due to an MSVC
compiler bug, since every (i64%int) operation will always yield a value
that can fit in an int, no?
I would not classify (int64 % int) warnings as a compiler bug, as the
standard states the result of the mod expression is the promoted type of
the two arguments. That being said, yes, (int64 % int) should always be
safe and in this case a simple cast would quiet the compiler, though at
the possible expense of future modifications being wrong (if for example
the int were ever changed to an int64 and the cast to int were not
changed, you'd have a potentially difficult to track down bug).
Personally, I try not to worry about warnings coming from third party
sources, as I don't want to maintain their code. What surprises me is
that this problem only appears in a 64 bit build? It seems to me it
should be reported in both 32 & 64 bit builds. Or maybe I'm assuming a
fact not in evidence.
SDR
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
