> 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.
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
On Tue, Apr 9, 2013 at 6:28 PM, David Empson 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
On 4/9/2013 7:06 PM, Nico Williams wrote:
On Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec 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 10/04/2013, at 11:06 AM, Nico Williams wrote:
> On Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec 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
On Tue, Apr 9, 2013 at 7:10 PM, Nico Williams 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
On Mon, Apr 8, 2013 at 9:10 AM, Michael Black 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 Mon, Apr 8, 2013 at 8:52 AM, Alexandr Němec 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
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 8 Apr 2013, at 3:10pm, Michael Black 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".
>
>
chard 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 &a
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
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...
-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 Sun, Apr 7, 2013 at 1:06 PM, Alexandr Němec 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;
>
On Mon, 2013-04-08 at 09:31 +0200, Kees Nuyt wrote:
> On Mon, 08 Apr 2013 08:39:49 +0200, Alexandr N?mec
> wrote:
>
> > Hi all,
> >
> > thanks for your replies, but unfortunately they did not answer
> > my original question whether these warnings are harmless and
> > can be
On Mon, 08 Apr 2013 08:39:49 +0200, Alexandr N?mec
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
Od: "Simon Slavin" <slav...@bigfraud.org>
Komu: <f...@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:
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.
>
>
> 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
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
21 matches
Mail list logo