This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] Update newlib so that it passes libc++'s tests
- From: Steven Abner <pheonix at zoomtown dot com>
- To: newlib at sourceware dot org
- Date: Wed, 18 Dec 2013 16:14:56 -0500
- Subject: Re: [PATCH] Update newlib so that it passes libc++'s tests
- Authentication-results: sourceware.org; auth=none
- Authentication-results: smtp01.cincibell.synacor.com smtp dot mail=pheonix at zoomtown dot com; spf=unknown; sender-id=unknown
- Authentication-results: smtp01.cincibell.synacor.com header dot from=pheonix at zoomtown dot com; sender-id=unknown
- Authentication-results: smtp01.cincibell.synacor.com smtp dot user=pheonix at zoomtown dot com; auth=pass (LOGIN)
- References: <CABdywOcnSpU=r5NGDDzhea4gxALh8LRL4A9vRY31wFjLhtF5zA at mail dot gmail dot com> <20131217094237 dot GA23189 at calimero dot vinschen dot de> <52B0B9CB dot 5090700 at LGSInnovations dot com> <20131217215832 dot GJ30010 at calimero dot vinschen dot de> <15F57421-0480-4EAD-9EBD-12EE71A421CE at zoomtown dot com> <20131218205850 dot GJ30010 at calimero dot vinschen dot de>
- X_cmae_category: 0,0 Undefined,Undefined
On 18 Dec 2013, at 3:58 PM, Corinna Vinschen wrote:
> On Dec 18 14:52, Steven Abner wrote:
>> On 17 Dec 2013, at 4:58 PM, Corinna Vinschen wrote:
>>> On Dec 17 15:53, Craig Howland wrote:
>>>> On 12/17/2013 04:42 AM, Corinna Vinschen wrote:
>>>>> On Dec 16 16:54, JF Bastien wrote:
>>>>>> +#ifndef WCHAR_MAX
>>>>>> #ifdef __WCHAR_MAX__
>>>>>> #define WCHAR_MAX __WCHAR_MAX__
>>>>>> +#elif defined(__WCHAR_UNSIGNED__)
>>>>>> +#define WCHAR_MAX 0xffffffffu
>>>>>> +#define WCHAR_MAX 0x7fffffffu
>>>>> and this is not quite ok. You're assuming that wchar_t is 4 bytes, but it
>>>>> isn't on all platforms. The fallbacks should take that into account,
>>>>> along the lines of
>>>>> #define WCHAR_MAX ((wchar_t)-1)
>>>> Unfortunately, this is not OK in general, as *_MAX defines are
>>>> required to be able to be used in preprocessor expressions, and
>>>> casts are not always allowed in them.
>>> Then it has to be done differently. The point is, you can't just set
>>> WCHAR_MAX to 0xffffffffu or 0x7fffffffu because it's wrong for some
>>> platforms. If the compiler doesn't provide the information, there has
>>> to be another way.
>> I have a question. The original post was about compiling newlib as the
>> C library. I thought newlib supports UTF32 encodings? If so then why
>> can't newlib use 0xffffffff? I can see how an embedded system could
>> redefine to 0xff if they only use ASCII. So if the original question one
>> that the person compiled using LLVM's libc++ without an architecture
>> defining wchar_t ?
> Not the C lib defines the size of wchar_t, the underlying system and the
> compiler does. On Windows-based systems like Cygwin, for instance,
> wchar_t is 2 bytes since that matches the UTF-16 UNICODE representation
> of the underlying Windows. Cygwin's gcc returns:
> #define __WCHAR_MAX__ 65535
> #define __WCHAR_MIN__ 0
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __WCHAR_TYPE__ short unsigned int
> #define __SIZEOF_WCHAR_T__ 2
> and the system designed of arbitrary embedded targets might do the same.
I knew of MS use of UTF-16, so I believed you verified that the system sets wchar_t
and that the compiler (GCC?) will honor it. So a designer of a UTF-8 system would
set __WCHAR_MAX__ 255 and will both MS and GCC and others honor this?
Thank you, I now know at least you can control compilers on this issue, rather than
typecasting the heck out of it.