This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update newlib so that it passes libc++'s tests


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
>>>>>> +#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 ?
> 
> 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.
Steve

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]