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


FWIW, I'm willing to wait if you guys are close to consensus on patch.  Otherwise, my intention
was to make the snapshot today.

My opinion is, if you can make it as good or better than it was and you can achieve the libc++
criteria, then fix the exceptions later.  It is a minor issue to add a macro in sys/config.h for
any platforms that don't have their compiler setting __WCHAR_MIN__ / __WCHAR_MAX__ and don't want
the logic below.

-- Jeff J.

----- Original Message -----
From: "JF Bastien" <jfb@chromium.org>
To: "Craig Howland" <howland@lgsinnovations.com>, "Joseph S. Myers" <joseph@codesourcery.com>
Cc: newlib@sourceware.org
Sent: Thursday, December 19, 2013 11:23:31 AM
Subject: Re: [PATCH] Update newlib so that it passes libc++'s tests

> 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


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