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: JF Bastien <jfb at chromium dot org>
- To: Craig Howland <howland at lgsinnovations dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Thu, 19 Dec 2013 11:23:31 -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> <Pine dot LNX dot 4 dot 64 dot 1312170153500 dot 29265 at digraph dot polyomino dot org dot uk> <CABdywOdE5rkMLOyK3NrM+k+OrpRLkbjPp5oddqDz9vv5wKkd0A at mail dot gmail dot com> <52B220A8 dot 4010901 at LGSInnovations dot com>
> There is a better way than guessing, but it is ugly: add a configure-time
> check that determines what the value is and puts it into the generated
> newlib.h (in a manner analogous to how _LDBL_EQ_DBL is, for example).
Good idea. I have a few questions:
* Would you want this to be in the current patch, or a different follow-up one?
* Would there be any compile-time flags that would change the wchar
representation, such that configure would pick up the compiler's
default and the user's compiled code would later get a different
representation?
* Should I get rid of the __WCHAR*__ checks entirely? I don't think I
should, but if the configure magic is correct then the
compiler-provided macros shouldn't be needed.
These fallbacks are there for compilers that provide neither one of
the __WCHAR_*__ macros nor the stdint.h/wchar.h builtin headers (GCC
and LLVM are fine, but I assume other compilers often used with newlib
may not be). Maybe the right solution is to teach newlib about these
compilers/platforms and what their wchar characteristics are? It seems
like newlib users have been content with the current hard-coded 32-bit
default, and I don't know enough about other users to know what the
"right thing" is in this case. Thanks for the guidance.
> The present wchar.h is broken in this manner already for WCHAR_MAX, so it
> might not be unreasonable to do this for wchar.h now and follow up with a
> fix for the existing MAX issue. It probably is not good, however, to add
> the breakage to stdint.h.
I assume you mean the "u" suffix Joseph also pointed out? I indeed
inadvertently carried it over from the previous wchar.h, but I don't
mind fixing it in this patch since (at Joel Sherrill's request) this
change probably won't land before the newlib release.
So make stdint.h and wchar.h:
#ifndef WCHAR_MIN
#ifdef __WCHAR_MIN__
#define WCHAR_MIN __WCHAR_MIN__
#elif defined(__WCHAR_UNSIGNED__) || (L'\0' - 1 > 0)
#define WCHAR_MIN (0 + L'\0')
#else
#define WCHAR_MIN (-0x7fffffff - 1 + L'\0')
#endif
#endif
#ifndef WCHAR_MAX
#ifdef __WCHAR_MAX__
#define WCHAR_MAX __WCHAR_MAX__
#elif defined(__WCHAR_UNSIGNED__) || (L'\0' - 1 > 0)
#define WCHAR_MAX (0xffffffffu + L'\0')
#else
#define WCHAR_MAX (0x7fffffff + L'\0')
#endif