4

If I convert the character 'ö' from a UTF-8 locale (where is is represented by the two octetts 0xC3 0xB6) to a wchar_t, I get a wchar_t value that is 0xF6. This applies to Linux and Solaris.

If I convert the character 'ö' from a ISO-8859-1 locale (where is is represented by the single octett 0xF6) to a wchar_t, I get a wchar_t value of 0xF6 on Linux and a value of 0x30000076 on Solaris.

Does anybody know the reason and is able to explan the background?

BTW: since the i18n sourcecode from Solaris is shared by Sun/Oracle, IBM and HP, there is a big chance that this applies to AIX and HP-UX as well.

  • 5
    Quoting The wchar_t mess: "On Solaris and FreeBSD, the wchar_t encoding is locale dependent and undocumented. [...] As a consequence, it is better to use multibyte strings." – Johan Myréen Aug 27 '18 at 17:20
  • The Wikipedia page on wide characters also contains an interesting quote: "The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text." – Johan Myréen Aug 27 '18 at 17:29
  • Unfortunately the related GNU text is not 100% correct and does not explain the backgound. What I was not aware of is that you cannot compare the wchar_t result from a mbtowc() call with the character constant 'ö' and this is not possible even when converting 'ö' results in 0xF6 since the constant 'ö' results in the signed value -10. – schily Aug 27 '18 at 17:57
  • Have you used setlocale (LC_CTYPE, "en_US.UTF-8") (or similar) beforehand? – Lorinczy Zsigmond Aug 31 '18 at 18:00
  • mbtowc() assumes the C locale if setlocale() was not called. The fact that there is different behavior in different locales should make it obvious that setlocale() has been called. – schily Aug 31 '18 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.