Re: [sqlite] 64bit compatibility warnings

[Dave McKee]

> 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.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Scott Robison]

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

Re: [sqlite] 64bit compatibility warnings

[Nico Williams]

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 binary 
> operator is an integer type larger than int then the other operand is first 
> converted to the larger type. Therefore p->nBuffer is converted from int to 
> i64 before doing the modulo operation.
>
> We now have i64 % i64, producing a result of type i64.
>
> The statement then stores that i64 result into an int. i64 conversion to int 
> without a cast produces the warning in MSVC (if int is 32-bit).

OK, that's fair.

> The only reason I can see not to have an explicit cast is that it risks 
> hiding a future bug if the types of the variables are changed.

Yes.  Casts to shut up a compiler/lint should be a last resort most often.

Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Igor Tandetnik]

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 (i64%int) operation will always yield a value
that can fit in an int, no?


Ok, thank for this comment. Of course, you are right, although I wouldn't
call it a compiler bug. The (i64%int) operation, gives an int result, but
allocated into an i64 value, so this is why the compiler reports the
warning. But thanks, it is obvious now, that these warnings can be ignored.


The compiler is complaining about an int64->int conversion, not the reverse.

Why on Earth would going from an int (64-bit or smaller) to an int64
cause a problem?


Without looking at the code, I imagine the result is ultimately assigned 
to an int variable. That's what triggers the warning. Something like this:


int64 A = ...;
int B = ...;
int C = A % B;

Formally, the type of the expression (A % B) is int64, thanks to 
integral promotion (chapter and verse from the C++ standard is available 
upon request). That result is then assigned to an int variable, formally 
necessitating a narrowing conversion, which triggers the warning.


However, the nature of modulo operator is such that the value of A % B 
is less than B, and since B is an int, the value of (A % B) is 
guaranteed to fit into an int without loss. A smarter compiler could 
have realized that, and suppressed the warning.


This is not technically a bug (defined as non-conformance with the 
standard), but a quality-of-implementation issue.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[David Empson]

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 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 are right, although I wouldn't
>> call it a compiler bug. The (i64%int) operation, gives an int result, but
>> allocated into an i64 value, so this is why the compiler reports the
>> warning. But thanks, it is obvious now, that these warnings can be ignored.
> 
> The compiler is complaining about an int64->int conversion, not the reverse.
> 
> Why on Earth would going from an int (64-bit or smaller) to an int64
> cause a problem?
> 
> 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.

One of the lines in question is:

Line 71133 iBuf = p->iReadOff % p->nBuffer;

iBuf is an int.

p->iReadOff is an i64.

p->nBuffer is an int.

C's usual arithmetic conversions specify that if either operand of a binary 
operator is an integer type larger than int then the other operand is first 
converted to the larger type. Therefore p->nBuffer is converted from int to i64 
before doing the modulo operation.

We now have i64 % i64, producing a result of type i64.

The statement then stores that i64 result into an int. i64 conversion to int 
without a cast produces the warning in MSVC (if int is 32-bit).

If the compiler was smarter, it would pay attention to the fact that the 
modulus cannot exceed the range of an int, therefore the warning is not 
necessary.

The only reason I can see not to have an explicit cast is that it risks hiding 
a future bug if the types of the variables are changed.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Richard Hipp]

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 could vary.  In
> practice though, the only architectures of any relevance where you're
> likely to find sizeof(int) != sizeof(int32_t) are Crays and 16-bit
> CPUs, and if SQLite3 doesn't claim to run on those then that's kinda
> good enough.
>

There are assert() statements to verify that variable size assumptions are
correct:

 http://www.sqlite.org/src/artifact/5f2c4fe72f6?ln=1860-1869




-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Nico Williams]

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".

Explicit casts shut up the compiler.  If that's all you want, well,
sure.  But explicit casts often hide bugs.  This one is a compiler
bug.

> Too bad one can't cast to the type of a variable though in C.

Well, one can, with GCC, but, yeah.

> 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 vary.  In
practice though, the only architectures of any relevance where you're
likely to find sizeof(int) != sizeof(int32_t) are Crays and 16-bit
CPUs, and if SQLite3 doesn't claim to run on those then that's kinda
good enough.

Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Nico Williams]

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 value
>> that can fit in an int, no?
>
> Ok, thank for this comment. Of course, you are right, although I wouldn't
> call it a compiler bug. The (i64%int) operation, gives an int result, but
> allocated into an i64 value, so this is why the compiler reports the
> warning. But thanks, it is obvious now, that these warnings can be ignored.

The compiler is complaining about an int64->int conversion, not the reverse.

Why on Earth would going from an int (64-bit or smaller) to an int64
cause a problem?

No, this is a compiler bug.

Nico
--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Igor Tandetnik]

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 "int" is 32 bits or larger.


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.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Simon Slavin]

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".
> 
> 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...:-)

You need consistency.  For any particular value either use int throughout or 
int64 throughout.  If you do need to convert cast the value explicitly.

The problem in SQLite is that it has to work with many different compilers and 
on many different platforms.  It is extremely difficult to make that happen and 
not get warnings from any of the compilers you're using.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Michael Black]

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 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

Re: [sqlite] 64bit compatibility warnings

[Alexandr Němec]

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 are right, although I wouldn't call 
it a compiler bug. The (i64%int) operation, gives an int result, but allocated 
into an i64 value, so this is why the compiler reports the warning. But thanks, 
it is obvious now, that these warnings can be ignored.
 
Alex
 

 
___
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

Re: [sqlite] 64bit compatibility warnings

[Jay A. Kreibich]

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 is nearly everything these days (and likely
  *everything* that supports an i64 type, even if running in 32-bit
  mode), but is not actually fixed by the language.


  Yeah, I don't buy it either.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Roland Hughes]

The short answer would be no.  It has been some time since I looked at the MS 
compiler, but, int and int64 are two entirely different data types...unless you 
use a compiler switch to FORCE 64-bit data types int is 32-bit and int64 is 
64-bit. 

http://software.intel.com/en-us/articles/size-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, 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

Re: [sqlite] 64bit compatibility warnings

[Richard Hipp]

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;
> 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

Re: [sqlite] 64bit compatibility warnings

[Roland Hughes]

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 ignored or not. These warnings reported by the VS C++
> > compiler are about "possible loss of data", so it is a
> > situation when a "int64" expression result is assigned to an
> > "int" variable for example. In such cases these warnings are
> > very legitimate. If such an assignment is the real intention
> > of the programmer, an explicit (int) typecast should be added,
> > because it will
> > 
> >- tell to the rest of the world, that the programmer knows
> >  what he is doing, ie. he really wants to "truncate" the result,
> 
> The programmers know what they are doing.
> As  tells, they are harmless if all
> tests scripts succeed. The test scripts are run before every SQLite
> release. SQLite is not released if a test fails. So, the warnings can be
> ignored.
> 


Or, it could be the tests simply don't exercise those possibilities.
I've been in IT far too long to trust that a test suite is "complete".


-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol
reserves.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Kees Nuyt]

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 about "possible loss of data", so it is a
> situation when a "int64" expression result is assigned to an
> "int" variable for example. In such cases these warnings are
> very legitimate. If such an assignment is the real intention
> of the programmer, an explicit (int) typecast should be added,
> because it will
> 
>- tell to the rest of the world, that the programmer knows
>  what he is doing, ie. he really wants to "truncate" the result,

The programmers know what they are doing.
As  tells, they are harmless if all
tests scripts succeed. The test scripts are run before every SQLite
release. SQLite is not released if a test fails. So, the warnings can be
ignored.

>- eliminate compiler warnings of this type.
>
> There are only 5 warning of this type in the entire code base,
> so that should be an easy fix.

Warnings are fixed eventually
( e.g.  ), 
but with a lower priority than making sure all tests succeed.
 
>Alex

-- 
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[Alexandr Němec]

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 
"possible loss of data", so it is a situation when a "int64" expression result is 
assigned to an "int" variable for example. In such cases these warnings are very legitimate. If 
such an assignment is the real intention of the programmer, an explicit (int) typecast should be added, 
because it will
 
- tell to the rest of the world, that the programmer knows what he is doing, ie. he 
really wants to "truncate" the result,
- eliminate compiler warnings of this type.
 
There are only 5 warning of this type in the entire code base, so that should 
be an easy fix.
 
Alex
__

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:


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...


One of the problems with compiler warnings is that different compilers generate warnings about 
different things.  So it's not "Get rid of 64-bit warnings" it's "Try to get rid of 
64--bit warnings in GCC without creating more of them in LCC and Visual C+, and try to get rid of 
them with all the different directives most people use most of the time.".  And it turns out 
that this is very difficult:

<http://www.sqlite.org/faq.html#q17 <http://www.sqlite.org/faq.html#q17>>

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users 
<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

Re: [sqlite] 64bit compatibility warnings

[Simon Slavin]

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 as doing so does not break 32-bit code...

One of the problems with compiler warnings is that different compilers generate 
warnings about different things.  So it's not "Get rid of 64-bit warnings" it's 
"Try to get rid of 64--bit warnings in GCC without creating more of them in LCC 
and Visual C+, and try to get rid of them with all the different directives 
most people use most of the time.".  And it turns out that this is very 
difficult:



Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 64bit compatibility warnings

[fred]

> 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

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 64bit compatibility warnings

[Alexandr Němec]

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   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
 
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. 
Thanks.
 
Continue your great SQLite work.
 
Alex
 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users