> printf-8.2...
> Expected: [2147483647 2147483648 4294967295]
> Got: [2147483647 18446744071562067968 18446744073709551615]
>
> The code looks like:
>
>
> ...
> do_test printf-8.2 {
> sqlite3_mprintf_int {%lu %lu %lu} 0x7fffffff 0x80000000 0xffffffff
> } {2147483647 2147483648 4294967295}
> ...
>
> where sqlite3_mprintf_int() is a Tcl function written in C that passes
> signed ints to a printf-like function with a format string that uses
> %lu. I think here we have sign extension going on. To me it seems
> clear that there's a bug in sqlite3_mprintf_int() -- why use %lu?
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.
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.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
