"Barrass, Richard" <[EMAIL PROTECTED]> wrote:
> Thanks for the help.
>
> I took a little while to extract our standard out ( It's multiplexed
> with the test harness results at current ).
>
> Here's the trace:-
>
> VDBE Execution Trace:
> SQL: [PRAGMA vdbe_trace=ON]
> 0 Expire 1 0
> 1 Halt 0 0
> VDBE Execution Trace:
> SQL: [SELECT * FROM sqlite_master]
> 0 Goto 0 14
> 14 Transaction 0 0
> 15 VerifyCookie 0 1
> 16 Goto 0 1
> 1 Integer 0 0 # sqlite_master
> Stack: i:619574286855700480
Hmmm.... Where is that big number coming from? The
hex value is 0x8992b8800000000. In other words, it appears
to set the lower 32-bits to zero correctly, but leave the
upper 32-bits in a random state. Here is the code that does
the setting:
case OP_Integer: {
pTos++;
pTos->flags = MEM_Int;
pTos->i = pOp->p1;
break;
}
The pOp->p1 value is 0 and is a 32-bit integer. pTos->i is a
64-bit integer.
More and more I suspect that your compiler is generating
incorrect code for assigning shorter integer values into a
64-bit integer.
Perhaps you will get better results on ARM if you recompile
using only 32-bit integers. (Do you need 64-bit integers
in your application? Probably not...)
Recompile with -DSQLITE_INT64_TYPE=int and -DSQLITE_32BIT_ROWID=1
and see if that doesn't help. Note that you must use the
-DSQLITE_INT64_TYPE=int option on any application that includes
the <sqlite3.h> header file as well.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
