[unixODBC-dev] The sizeof(SQL_C_WCHAR) mess

Marc Herbert 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

 <nttp://news.gmane.org/gmane.comp.db.unixodbc.devel/494/>





More information about the unixODBC-dev mailing list