[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
