Which is why...IMHO....to avoid all the repeats of this question in the future (and from the past)....one should simply to do the cast to int and put a comment on the line that says " % int always fits in an int".
Too bad one can't cast to the type of a variable though in C. And if IBuf is an int do you really want that to be a 64-bit int on a 64-bit compiler? Would IBuf ever get that big or need be that big? Yes...I know I sound like IBM now...:-) -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp Sent: Monday, April 08, 2013 6:41 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] 64bit compatibility warnings On Sun, Apr 7, 2013 at 1:06 PM, Alexandr Němec <a.ne...@atlas.cz> 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? -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
