On Fri, Jun 20, 2008 at 10:15:09PM -0400, Eric Minbiole wrote: > I agree that you are on the right track-- the format doesn't portably > match the values. However, I think the %lu part is correct-- "long" is > the only C type guaranteed to be at least 32 bits. Instead, I think the > issue is that the hex constants are not explicitly specified as longs, > so the compiler is treating them as normal int's, causing the mismatch. > > Rather than a sign extension problem, I believe the compiler is reading > 8 bytes of parameter data from the stack for each %lu, versus the 4 > bytes supplied. As confirmation of this, note that 18446744071562067968 > = FFFFFFFF80000000 hex-- the 2nd and 3rd parameters combined.
Ah, good catch. And that would explain (or begin to) why it occurs on SPARCv9 but not amd64. > I think it's a simple matter of adding the 'L' suffix to the constants. > I.e., 0x7fffffffL, 0x80000000L, etc. This should work portably across > 32/64 bit platforms. I'll try it. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
