Look I'm certain you mean well, but the rest of us are pretty busy using one of the best small footprint databases on the planet. That means we are way too busy to nit-pic a good product to pieces, just because it won't compile clean using Mickeysoft's latest and greatest.
How' bout you go through this buggy code and fix all your concerns then upload it to CVS. That way you would be making a huge contribution to us all, and won't come off as such an irritating whiner. Fred > -----Original Message----- > From: Dirk Zabel [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 30, 2005 3:59 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] SQLite as a Windows kernel tool > > > [EMAIL PROTECTED] schrieb: > > >Ken & Deb Allen <[EMAIL PROTECTED]> wrote: > > > > > >>vdbeapi.c > >>e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' : > >>conversion from 'i64' to 'int', possible loss of data > >>e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' : > conversion > >>from 'double' to 'i64', possible loss of data > >>e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' : > conversion > >>from 'double' to 'u64', possible loss of data > >> > >> > >> > > > >What about these three warnings do you think is a concern? > >Have you actually looked at the code in question to see > >if the possibility of data loss is real and unintentional? > >What makes you think that these warnings are not just a case > >of the compiler blowing smoke? > > > >-- > >D. Richard Hipp <[EMAIL PROTECTED]> > > > > > > > > > These concerns seem to me not unfounded. > Just looking at the three cited positions in vdbeapi.c, i find: > Line 55: the conversion i64->int might be ok, depends on the > runtime-argument pVal. I am not sure. > Line 195: this conversion double->i64 is done by intent; > giving the > number of nanoseconds since midnight. I think a > cast to int64 would be appropriate to express this intent. I comment > might help to see the reason, but on the other hand the code > looks quite > obvious here. > Line 232: same conversion, insofar applies the same remark. > But what if > between the computation of startTime and rNow midnight > occurred? I guess > there would be a wrap-around - an error in my point of view. > > I don't think it's a good idea to assume a compiler warning > about type > conversions are "blowing smoke". At least, they should be > eliminated in > order not to cover messages about real quirks. > > Regards > Dirk >
