[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150220042602.GQ23507@brightrain.aerifal.cx>
Date: Thu, 19 Feb 2015 23:26:02 -0500
From: Rich Felker <dalias@...c.org>
To: Sergey Dmitrouk <sdmitrouk@...esssoftek.com>
Cc: musl@...ts.openwall.com
Subject: Re: wchar_t and -fshort-wchar
On Wed, Feb 18, 2015 at 12:53:37PM +0200, Sergey Dmitrouk wrote:
> Hi,
>
> musl seems to build fine with -fshort-wchar, but when client applications
> 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.
>
> 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.
musl does not support configurations with under-sized definitions of
types like 16-bit wchar_t or 32-bit off_t. Only the sizes that can
represent the full range of values are supported. musl does however
have the C11 uchar.h functions which can operate on char16_t, so you
could use char16_t and the corresponding c16 conversion functions
instead of the wc versions if that helps. What are you trying to
achieve?
Rich
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.
