This is the mail archive of the
newlib@sourceware.org
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 14:52:52 -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>
- X_cmae_category: 0,0 Undefined,Undefined
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
>>>> +#else
>>>> +#define WCHAR_MAX 0x7fffffffu
>>>> #endif
>>> 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.
Hi
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 ?
I ask because my understanding was it was a "keyword" like int and
long that is set by a compiler, based on guessing system's encoding schemes.
Supposedly from C90: "an integral type whose range of values can represent
distinct codes for all members of the largest extended character set specified
among the supported locales". And that the wchar_t functions are functions
that accept multibyte encodings up to 32bits, since I personally dont know
any 64bit encodings. But again a system that uses Latin1 encodings defines
as an 8bit wchar_t.
Sorry about interruption, but important to me as a code designer.
Steve