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: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 18 Dec 2013 16:28:26 -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>
> > >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 may be wrong, but the hard-coded 32-bit size is a fallback if all
else fails. Really the compiler knows best, and that what
__WCHAR_{MIN,MAX}__ are there for. If all else fails then there is no
better way that I know (please let me know if there is).
Not that it's much of an argument but my patch isn't making things
*worst* with the 32-bit assumption (it was already there) it's merely
being correct when then compiler provides information. If anything
fixing that broken assumption may inadvertently break people who rely
on it today.