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