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
By definition, A % B B. Thus, if B fits into an int (be it 32-bit or
16-bit or otherwise), then A % B would too.
I'm not sure this is *strictly* true if negative numbers are involved; e.g.
-4 % -3 = -1.
But it's still true to say it's closer to zero, and thus should always fit
into an int.
-of-long-integer-type-on-different-architecture-and-os
From: sqlite-users-boun...@sqlite.org on behalf of Richard Hipp
Sent: Monday, April 08, 2013 7:41 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] 64bit compatibility warnings
On Sun, Apr 7
On Mon, Apr 08, 2013 at 07:41:20AM -0400, Richard Hipp scratched on the wall:
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?
Only on systems where int is 32 bits or larger.
OK, yes... that
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?
Ok, thank for this comment. Of course, you
: 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
On 8 Apr 2013, at 3:10pm, Michael Black mdblac...@yahoo.com wrote:
Which is why...IMHOto 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
On 4/8/2013 9:51 AM, Jay A. Kreibich wrote:
On Mon, Apr 08, 2013 at 07:41:20AM -0400, Richard Hipp scratched on the wall:
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?
Only on systems where
On Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec a.ne...@atlas.cz wrote:
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
On Mon, Apr 8, 2013 at 9:10 AM, Michael Black mdblac...@yahoo.com wrote:
Which is why...IMHOto 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.
On Tue, Apr 9, 2013 at 7:10 PM, Nico Williams n...@cryptonector.com wrote:
And if IBuf is an int do you really want that to be a 64-bit int on a
64-bit compiler?
That's a different story. SQLite3 and just about everything should be
using specific int sizes precisely because they could
On 10/04/2013, at 11:06 AM, Nico Williams n...@cryptonector.com wrote:
On Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec a.ne...@atlas.cz wrote:
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
On 4/9/2013 7:06 PM, Nico Williams wrote:
On Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec a.ne...@atlas.cz wrote:
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
On Tue, Apr 9, 2013 at 6:28 PM, David Empson demp...@emptech.co.nz wrote:
No, this is a compiler bug.
It is not a compiler bug. It is a failure of the compiler to deduce that the
warning is unnecessary.
[...]
C's usual arithmetic conversions specify that if either operand of a binary
...@cetussoft.com, General Discussion of SQLite Database
sqlite-users@sqlite.org
Datum: 07.04.2013 20:05
Předmět: Re: [sqlite] 64bit compatibility warnings
On 7 Apr 2013, at 6:26pm, f...@cetussoft.com wrote:
I think that in general it might be a good idea to update the code to
not produce any 64
On Mon, 08 Apr 2013 08:39:49 +0200, Alexandr N?mec a.ne...@atlas.cz
wrote:
Hi all,
thanks for your replies, but unfortunately they did not answer
my original question whether these warnings are harmless and
can be ignored or not. These warnings reported by the VS C++
compiler are about
On Mon, 2013-04-08 at 09:31 +0200, Kees Nuyt wrote:
On Mon, 08 Apr 2013 08:39:49 +0200, Alexandr N?mec a.ne...@atlas.cz
wrote:
Hi all,
thanks for your replies, but unfortunately they did not answer
my original question whether these warnings are harmless and
can be ignored or not.
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:
Dear all,
when compiling the latest 3.7.16.1 version of SQLite, the VS compiler complains
about some 64 bit portability issues, see below. May these warning be safely
ignored when compiling 64 bit? All warnings refer to the sqlite3.c amalgamation
file. Thanks in advance.
Line 6766
I think that in general it might be a good idea to update the code to
not produce any 64 bit portability warnings, so that we know for sure,
that compiling 64 bit does not introduce any 64 bit side effects or possible
bugs.
...as long as doing so does not break 32-bit code...
Fred
On 7 Apr 2013, at 6:26pm, f...@cetussoft.com wrote:
I think that in general it might be a good idea to update the code to
not produce any 64 bit portability warnings, so that we know for sure,
that compiling 64 bit does not introduce any 64 bit side effects or possible
bugs.
...as long
21 matches
Mail list logo
