Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
[EMAIL PROTECTED] wrote: "Ian Frosst" <[EMAIL PROTECTED]> wrote: Looking at the code, there are pointer to int truncations everywhere, Where, specifically, are you seeing pointer to int truncations in the SQLite code base? This is something that needs to be fixed. I've compiled 3.3.10 (plus check-in 3590 and 3592) using Embedded Visual C++ 4.0 to do testing on WinCE and received a number of similar warnings. Two are listed below: btree.c(3951) : warning C4244: '+=' : conversion from '__int64 ' to 'int ', possible loss of data btree.c(3953) : warning C4244: '=' : conversion from '__int64 ' to 'int ', possible loss of data A number of other warnings in btree.c are about a CellInfo.nKeys and BtCursor.nKey value being converted to an int. -- Scott Wilkinson - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
"Ian Frosst" <[EMAIL PROTECTED]> wrote:
> the two suspects I see in the warnings are:
>
> static int winFileHandle(OsFile *id)
> {
>return (int)((winFile*)id)->h;
> }
>
> The HANDLE will be64 bit, then get trunc'd when cast (unless there is some
> compiler magic afoot that I'm not aware of.)
winFileHandle is used only to print (using %d) the file handle
for debugging purposes. If you do not enable debugging, this
routine is never used. And even if you do, the truncation will
not matter. This is nothing to worry about. I suppose I
should add a comment to that effect
>
> And, in vtab.c(573)
>
> int sqlite3VtabCommit(sqlite3 *db)
> {
>callFinaliser(db, (int)(&((sqlite3_module *)0)->xCommit));
>return SQLITE_OK;
> }
>
> the explicit cast of the commit function pointer to int could be a
> truncation operation (though looking deeper into this one, it looks like
> that's not used as a pointer directly, but as an offset, so I could be off
> base.)
>
This appears to be taking an offset. I'll look into it further when
I get a chance.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SQLite works fine on 64 bit platforms. In my case I am using Linux 64bit. The warnings are about pointers being cast to int. > Looking at the code, there are pointer to int truncations > everywhere, Pointers are used as placeholders in callbacks. For example if you register a function, you supply a chunk of data in the form of a void pointer that is supplied to you again when the function is called. If your data really was an int, then you'd convert to void* at registration, and then convert from void* in the callback. That is not an error nor if information lost. > and I've found no magic bullet for declalring int's as 64 bit > (__int64 and longlong is how I normally do it.) No platform uses 64 bit ints. Every common 64 bit platform uses 32 bit ints. Microsoft was unique in also using 32 bit longs while everyone else uses 64 bit longs. Somehow convincing sqlite to use 64 bit ints won't solve your problem. You need to show what your other errors are. BTW SQLite is limited to 2GB for strings and blobs even on 64 bit platforms due to using int in the api for the size of various things. Not that shoving such large objects into the database is a good idea anyway. http://www.sqlite.org/cvstrac/tktview?tn=2125 Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFrHX+mOOfHg372QQRAlsyAJ9qiydtFUptvjruaPAJi02vCkD9VACgzp5y QIAjOieKHwMFjVzTctKEDDg= =GIOt -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
--- [EMAIL PROTECTED] wrote: > "Ian Frosst" <[EMAIL PROTECTED]> wrote: > > Looking at the code, there are pointer to int truncations > > everywhere, > > Where, specifically, are you seeing pointer to int truncations > in the SQLite code base? I haven't seen any. I suspect there aren't any. As for his comment on the lack of a 64 bit datatype, he did not look very hard... #ifdef SQLITE_INT64_TYPE typedef SQLITE_INT64_TYPE sqlite_int64; typedef unsigned SQLITE_INT64_TYPE sqlite_uint64; #elif defined(_MSC_VER) || defined(__BORLANDC__) typedef __int64 sqlite_int64; typedef unsigned __int64 sqlite_uint64; #else typedef long long int sqlite_int64; typedef unsigned long long int sqlite_uint64; #endif Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite 3.3.10 compilation with VC++ for Win64
"Ian Frosst" <[EMAIL PROTECTED]> wrote: > Looking at the code, there are pointer to int truncations > everywhere, Where, specifically, are you seeing pointer to int truncations in the SQLite code base? This is something that needs to be fixed. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] SQLite 3.3.10 compilation with VC++ for Win64
Has anyone here gotten 3.3.10 (or any subsequent version) to compile and run successfully through Visual C++ (I'm using 2005, but again, any version would do.) Looking at the code, there are pointer to int truncations everywhere, and I've found no magic bullet for declalring int's as 64 bit (__int64 and longlong is how I normally do it.) If there really is no way to get VC++ to work, would it be fair to assume that I have to get a 64 bit version of gcc, and use that to do the compilation (I've read that it will compile int to 64 bit)? Thanks, Frosstoise
