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: Craig Howland <howland at LGSInnovations dot com>
- To: newlib at sourceware dot org
- Date: Wed, 18 Dec 2013 16:28:37 -0500
- Subject: Re: [PATCH] Update newlib so that it passes libc++'s tests
- Authentication-results: sourceware.org; auth=none
- 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> <A988294C-2DF6-41BE-B1AA-B1F51EDA2A51 at zoomtown dot com>
On 12/18/2013 04:14 PM, Steven Abner wrote:
The user does not set __WCHAR_MAX__ to control the compiler. Rather, that is the
assumed method by which the compiler communicates to the user/library what it is
using (based on compiler settings, options, etc.) The problem arises in the
case in the innermost history in this email, at the #else, if the compiler has
not set __WCHAR_MAX__ to the value it is using. Newlib is reduced to deriving
the number on its own. The cast method makes it not a guess, being directly
taken from the compiler, but is illegal. Therefore, we need a different method
to know what value to use, as simply hard-coding 0xFFFFFFFF (as a guess) would
not always be correct. That is, the issue is not controlling the compiler, but
when the compiler does not communicate what it knows in a manner that we know.
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:
#define WCHAR_MAX __WCHAR_MAX__
+#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.