2010/10/4 Mikael Helbo Kjær <[email protected]> > About the MIB_IFROW::wszName field isn’t it just a question of how the > WCHAR define ends up. If you expect a MBCS value and a string is UNICODE a > conversion function (mbstowcs_s) is available AFAIK even with the > /Zc:wchar_t- value set in the compiler no matter if the compiler treats > wchar_t as a native type or a define to unsigned short (which is what is > does with the above option set). > > > Really? All the APIs are declared with wchar_t not WCHAR, only WCHAR has the fallback to unsigned short.
#if !defined(_NATIVE_WCHAR_T_DEFINED) typedef unsigned short WCHAR; #else typedef wchar_t WCHAR; #endif http://msdn.microsoft.com/en-us/library/ms684497(VS.85).aspx Wouldn't lack of wchar_t imply the absence of all the related APIs? The GetAdapterAddresses API returns an ANSI adapter name and the only way to match this with GetIfEntry is to use wcstombs_s on the WCHAR type in its result. On a Chinese desktop with Unicode adapter names this works as expected so my hypothesis is that GetIfEntry is just returning a wide up-converted version of the ANSI name. I could therefore simulate wcstombs_s by dropping the high bytes. Otherwise what changes are required to placate Qt's lack of support for a wchar_t native type? I only specify the data type in an optional module not built with 0MQ so it should be moot for compatibility. -- Steve-o
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
