[unixODBC-dev] The sizeof(SQL_C_WCHAR) mess
Marc.Herbert at continuent.com
Mon Nov 21 16:19:27 GMT 2005
"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com> writes:
> About SQLWCHAR I think is the worst problem in unixODBC design... if
> anyone wants my opinion on how to make APIs ABI compatible let SQLWCHAR
> be wchar_t.
Assume some unix application is using ODBC. The unix in question has:
sizeof(wchar_t) = 4 and UCS-4 (non-)encoding. The application stores
and retrieves strings using the ODBC type "SQL_C_WCHAR". So far all
this looks quite common to me.
Is this application supposed to convert UTF-16 to UCS-4 manually?
I mean, does _every_ unix driver uses 2-bytes characters? "Most"
drivers only? Depends on compile-time configuration? Anything else?
Sure Microsoft defines SQL_C_WCHAR as "unicode", and unicode as "2
bytes": UCS-2 or more recently UTF-16. By the way using wchar_t for
UTF-16 defeats the main purpose of wchar_t, but I digress. So one
could naively shortcut: SQL_C_WCHAR is 2 bytes...
... but the (unix) issue is:
- the whole idea of SQL_C_WCHAR looks like to relieve the application
of conversions issues.
- "Unicode" does not fit into 2 bytes anymore (thus the
UTF-16 into wchar_t ugliness)
What do real-world ODBC applications assume about sizeof(SQL_C_WCHAR)?
Thanks a lot in advance.
See also thread "SQL_WCHART_CONVERT" above
More information about the unixODBC-dev