Hello, The handling of long values has been recently changed to map to either x_integer or x_long_long SOCI internal type depending on sizeof(long) in the program. But "unsigned long" remains mapped to its own special x_unsigned_long type which is always mapped to 64 bit long long (SQL_BIGINT) in ODBC backend. This is inconsistent: not only unsigned long is treated completely different from long, but it's also handled in a very different way from other unsigned types such as "unsigned short" and "unsigned int" which don't have any special exchange type defined for them.
Moreover, looking at the code dt_unsigned_long is only used in 2 places: in PostgreSQL and SQLite backends. In the former it's used to represent an OID which is always 32 bits so it would really make much more sense to use x_integer for it (as SOCI clearly relies on sizeof(int)==4 anyhow). For SQLite I'm less sure but it seems that handling "unsigned int" as "int" is at least as good as handling it as "unsigned long" -- and, as I said above, more consistent. So what about simply removing dt_unsigned_long and x_unsigned_long? AFAICS they're quite unnecessary, inconsistent with the other types and currently broken in ODBC (because unsigned int definitely shouldn't be mapped to 8 byte SQL_BIGINT). Are there any objections to doing this? Would it break anything? VZ
pgpGZdtkv92ox.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
