Date: Wed, 18 Feb 2015 12:54:13 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: wchar_t and -fshort-wchar * Sergey Dmitrouk <sdmitrouk@...esssoftek.com> [2015-02-18 12:53:37 +0200]: > musl seems to build fine with -fshort-wchar, but when client applications that cannot possibly work wchar_t is assumed to be a unicode code point so short wchar_t is broken > are built against musl all uses of wide character literals fail due to wide > type defined internally by a compiler differs from the type of `wchar_t` in > musl headers. > > I faced this on ARM where `wchar_t` is defined as `unsigned int` by > musl but it's `unsigned short` from compilers point of view. I'd expect > similar issues with other targets. > http://arminfo.emea.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf says "The preferred type of wchar_t is unsigned int. However, a virtual platform may elect to use unsigned short instead. A platform standard must document its choice" on musl/glibc/.. the platform standard is unsigned int > Would it make sense to use `__WCHAR_TYPE__` for `wchar_t` when it's > available (it's already used for i386, but for different reason)? > Presumably, as compiler is responsible for creating wide literals, libc > would better agree with it on the type. > > Of course, this makes sense only if you intend to support builds with > `-fshort-wchar` flag, which are not very common I believe. > this is an abi change so a different loader path name etc should be used then (you should create a new subarch in musl's terminology) but i'm not sure how you plan to fix up mb to wc functions for such a subarch.. > Best regards, > Sergey
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.