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

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

[Jonathan Roelofs]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

(For context, here's the original thread: 
https://sourceware.org/ml/newlib/2013/msg01077.html)

I've rebased the remaining part of the original patch.  Please see the attached. 
Is this good for commit, or does it still need work?


Cheers,
Jon

-- 
Jon Roelofs
jonathan@codesourcery.com
CodeSourcery / Mentor Embedded

[-- Attachment #2: newlib_libcxx.diff --]
[-- Type: text/plain, Size: 1836 bytes --]

diff --git a/src/newlib/libc/include/stdlib.h b/src/newlib/libc/include/stdlib.h
index dee9ed6..374b9b6 100644
--- a/src/newlib/libc/include/stdlib.h
+++ b/src/newlib/libc/include/stdlib.h
@@ -151,7 +151,12 @@ long    _EXFUN(a64l,(const char *__input));
 char *  _EXFUN(l64a,(long __input));
 char *  _EXFUN(_l64a_r,(struct _reent *,long __input));
 int	_EXFUN(on_exit,(_VOID (*__func)(int, _PTR),_PTR __arg));
+#endif
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 _VOID	_EXFUN(_Exit,(int __status) _ATTRIBUTE ((__noreturn__)));
+#ifndef __STRICT_ANSI__
 int	_EXFUN(putenv,(char *__string));
 int	_EXFUN(_putenv_r,(struct _reent *, char *__string));
 _PTR	_EXFUN(_reallocf_r,(struct _reent *, _PTR, size_t));
@@ -189,12 +194,20 @@ unsigned short *
        _EXFUN(_seed48_r,(struct _reent *, unsigned short [3]));
 _VOID  _EXFUN(srand48,(long));
 _VOID  _EXFUN(_srand48_r,(struct _reent *, long));
+#endif
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(atoll,(const char *__nptr));
+#endif
+#ifndef __STRICT_ANSI__
 long long _EXFUN(_atoll_r,(struct _reent *, const char *__nptr));
+#endif
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(llabs,(long long));
 lldiv_t	_EXFUN(lldiv,(long long __numer, long long __denom));
-#endif /* ! __STRICT_ANSI__ */
-#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
 long long _EXFUN(strtoll,(const char *__restrict __n, char **__restrict __end_PTR, int __base));
 #endif
 #ifndef __STRICT_ANSI__

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

[Thomas Uhle]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Fri, 2014-09-19 at 16:40 -0600, Jonathan Roelofs wrote:

> (For context, here's the original thread: 
> https://sourceware.org/ml/newlib/2013/msg01077.html)
> 
> I've rebased the remaining part of the original patch.  Please see the attached. 
> Is this good for commit, or does it still need work?
> 
> 
> Cheers,
> Jon
> 

Hi Jon,

your patch is missing an #endif and you would also have to replace every

  (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \

by

  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \

to make it work correctly. However, your patch is part of the patch that
I sent on September 9th and which is attached to this e-mail again.

Best regards,

Thomas Uhle


[-- Attachment #2: newlib_long_long_support.diff --]
[-- Type: text/x-patch, Size: 5906 bytes --]

--- newlib/libc/include/math.h	27 Aug 2014 19:27:03 -0000	1.52
+++ newlib/libc/include/math.h	9 Sep 2014 17:37:27 -0000
@@ -136,7 +136,8 @@
 #endif /* ! defined (__math_68881) */
 #endif /* ! defined (_REENT_ONLY) */
 
-#if !defined(__STRICT_ANSI__) || defined(__cplusplus) || __STDC_VERSION__ >= 199901L
+#if !defined(__STRICT_ANSI__) || defined(__cplusplus) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L)
 
 /* ISO C99 types and macros. */
 
@@ -276,7 +277,7 @@
 extern _LONG_LONG_TYPE int llrint _PARAMS((double));
 extern double round _PARAMS((double));
 extern long int lround _PARAMS((double));
-extern long long int llround _PARAMS((double));
+extern _LONG_LONG_TYPE int llround _PARAMS((double));
 extern double trunc _PARAMS((double));
 extern double remquo _PARAMS((double, double, int *));
 extern double fdim _PARAMS((double, double));
@@ -343,10 +344,10 @@
 extern float tgammaf _PARAMS((float));
 extern float nearbyintf _PARAMS((float));
 extern long int lrintf _PARAMS((float));
-extern _LONG_LONG_TYPE llrintf _PARAMS((float));
+extern _LONG_LONG_TYPE int llrintf _PARAMS((float));
 extern float roundf _PARAMS((float));
 extern long int lroundf _PARAMS((float));
-extern long long int llroundf _PARAMS((float));
+extern _LONG_LONG_TYPE int llroundf _PARAMS((float));
 extern float truncf _PARAMS((float));
 extern float remquof _PARAMS((float, float, int *));
 extern float fdimf _PARAMS((float, float));
@@ -429,7 +430,7 @@
 extern long double tgammal _PARAMS((long double));
 extern long double nearbyintl _PARAMS((long double));
 extern long int lrintl _PARAMS((long double));
-extern long long int llrintl _PARAMS((long double));
+extern _LONG_LONG_TYPE int llrintl _PARAMS((long double));
 extern long double roundl _PARAMS((long double));
 extern long lroundl _PARAMS((long double));
 extern _LONG_LONG_TYPE int llroundl _PARAMS((long double));
@@ -452,11 +453,11 @@
 /* Other long double precision functions.  */
 extern _LONG_DOUBLE rintl _PARAMS((_LONG_DOUBLE));
 extern long int lrintl _PARAMS((_LONG_DOUBLE));
-extern _LONG_LONG_TYPE llrintl _PARAMS((_LONG_DOUBLE));
+extern _LONG_LONG_TYPE int llrintl _PARAMS((_LONG_DOUBLE));
 #endif /* __i386__ */
 #endif /* !_LDBL_EQ_DBL */
 
-#endif /* !defined (__STRICT_ANSI__) || defined(__cplusplus) || __STDC_VERSION__ >= 199901L */
+#endif /* !defined (__STRICT_ANSI__) || defined(__cplusplus) || (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) */
 
 #if !defined (__STRICT_ANSI__) || defined(__cplusplus)
 
--- newlib/libc/include/stdlib.h	1 Aug 2014 15:44:50 -0000	1.51
+++ newlib/libc/include/stdlib.h	9 Sep 2014 17:37:27 -0000
@@ -130,7 +130,9 @@
 _VOID	_EXFUN(srand,(unsigned __seed));
 double	_EXFUN(strtod,(const char *__restrict __n, char **__restrict __end_PTR));
 double	_EXFUN(_strtod_r,(struct _reent *,const char *__restrict __n, char **__restrict __end_PTR));
-#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 float	_EXFUN(strtof,(const char *__restrict __n, char **__restrict __end_PTR));
 #endif
 #ifndef __STRICT_ANSI__
@@ -151,7 +153,13 @@
 char *  _EXFUN(l64a,(long __input));
 char *  _EXFUN(_l64a_r,(struct _reent *,long __input));
 int	_EXFUN(on_exit,(_VOID (*__func)(int, _PTR),_PTR __arg));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 _VOID	_EXFUN(_Exit,(int __status) _ATTRIBUTE ((__noreturn__)));
+#endif
+#ifndef __STRICT_ANSI__
 int	_EXFUN(putenv,(char *__string));
 int	_EXFUN(_putenv_r,(struct _reent *, char *__string));
 _PTR	_EXFUN(_reallocf_r,(struct _reent *, _PTR, size_t));
@@ -189,18 +197,28 @@
        _EXFUN(_seed48_r,(struct _reent *, unsigned short [3]));
 _VOID  _EXFUN(srand48,(long));
 _VOID  _EXFUN(_srand48_r,(struct _reent *, long));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(atoll,(const char *__nptr));
+#endif
+#ifndef __STRICT_ANSI__
 long long _EXFUN(_atoll_r,(struct _reent *, const char *__nptr));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(llabs,(long long));
 lldiv_t	_EXFUN(lldiv,(long long __numer, long long __denom));
-#endif /* ! __STRICT_ANSI__ */
-#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
 long long _EXFUN(strtoll,(const char *__restrict __n, char **__restrict __end_PTR, int __base));
 #endif
 #ifndef __STRICT_ANSI__
 long long _EXFUN(_strtoll_r,(struct _reent *, const char *__restrict __n, char **__restrict __end_PTR, int __base));
 #endif /* ! __STRICT_ANSI__ */
-#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 unsigned long long _EXFUN(strtoull,(const char *__restrict __n, char **__restrict __end_PTR, int __base));
 #endif
 #ifndef __STRICT_ANSI__
@@ -232,7 +250,9 @@
 
 /* On platforms where long double equals double.  */
 #ifdef _HAVE_LONG_DOUBLE
-#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 extern long double strtold (const char *__restrict, char **__restrict);
 #endif
 #endif /* _HAVE_LONG_DOUBLE */

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

[Jonathan Roelofs]

On 9/22/14 5:40 AM, Thomas Uhle wrote:
> On Fri, 2014-09-19 at 16:40 -0600, Jonathan Roelofs wrote:
>
>> (For context, here's the original thread:
>> https://sourceware.org/ml/newlib/2013/msg01077.html)
>>
>> I've rebased the remaining part of the original patch.  Please see the attached.
>> Is this good for commit, or does it still need work?
>>
>>
>> Cheers,
>> Jon
>>
>
> Hi Jon,
>
> your patch is missing an #endif
Good catch!
> and you would also have to replace every
>
>    (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \
>
> by
>
>    (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
Oh, yeah, you're right, another good point.
>
> to make it work correctly. However, your patch is part of the patch that
> I sent on September 9th and which is attached to this e-mail again.
Excellent. Here's a link to the thread to save other folks looking for it: 
https://sourceware.org/ml/newlib/2014/msg00418.html

With that, I'll yield to your patch's review as it subsumes mine.


Cheers,

Jon
>
> Best regards,
>
> Thomas Uhle
>

-- 
Jon Roelofs
jonathan@codesourcery.com
CodeSourcery / Mentor Embedded

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

[JF Bastien]

> Ok.  I will delay the snapshot until you resubmit the patch.  It passes additional
> tests from libc++ so it is a step forward and we might as well make it part of the
> snapshot.

I re-ran the libc++ testsuite with the wchar.h fixes suggested, and
excluding all stdint.h modifications. There are 3 new failures, all
due to stdint.h:
  libc++::input.output/file.streams/c.files/cinttypes.pass.cpp: libc++
  libc++::language.support/cstdint/cstdint.syn/cstdint.pass.cpp: libc++
  libc++::depr/depr.c.headers/stdint_h.pass.cpp: libc++
As discussed on this thread I'll fix stdint.h after the release, and
will also add a configure-time detection of what the default should be
for WCHAR_{MIN,MAX} when the compiler doesn't already define a macro.

FWIW I have exclusions on other tests that I'll fix later. Those that
I think are shortcomings of newlib are caused by:
 * Lack of fenv.h for my particular setup.
 * Lack of uchar.h from C Unicode TR.
 * Lack of C11's [at_]quick_exit.
libc++ also has its own shortcomings, some of which I've submitted a
patch for, and others that I will also fix later. Overall though the
libc++/newlib combination now passes most of libc++'s testsuite when
it used to fail quite a lot of them.


Here is an updated patch. If it looks good, could someone with access commit it?


Index: newlib/libc/include/limits.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/limits.h,v
retrieving revision 1.3
diff -u -r1.3 limits.h
--- newlib/libc/include/limits.h 31 Oct 2008 21:03:41 -0000 1.3
+++ newlib/libc/include/limits.h 17 Dec 2013 00:40:00 -0000
@@ -96,7 +96,8 @@
 #    define __LONG_LONG_MAX__ 9223372036854775807LL
 #   endif

-#   if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+#   if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) ||   \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 /* Minimum and maximum values a `signed long long int' can hold.  */
 #    undef LLONG_MIN
 #    define LLONG_MIN (-LLONG_MAX-1)
@@ -143,4 +144,3 @@
 #ifndef PATH_MAX
 #define PATH_MAX 4096
 #endif
-
Index: newlib/libc/include/stdlib.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/stdlib.h,v
retrieving revision 1.48
diff -u -r1.48 stdlib.h
--- newlib/libc/include/stdlib.h 20 Nov 2013 09:46:39 -0000 1.48
+++ newlib/libc/include/stdlib.h 17 Dec 2013 00:40:00 -0000
@@ -39,7 +39,9 @@
   long rem; /* remainder */
 } ldiv_t;

-#ifndef __STRICT_ANSI__
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 typedef struct
 {
   long long int quot; /* quotient */
@@ -149,7 +151,13 @@
 char *  _EXFUN(l64a,(long __input));
 char *  _EXFUN(_l64a_r,(struct _reent *,long __input));
 int _EXFUN(on_exit,(_VOID (*__func)(int, _PTR),_PTR __arg));
-_VOID _EXFUN(_Exit,(int __status) _ATTRIBUTE ((noreturn)));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
+_VOID  _EXFUN(_Exit,(int __status) _ATTRIBUTE ((noreturn)));
+#endif
+#ifndef __STRICT_ANSI__
 int _EXFUN(putenv,(char *__string));
 int _EXFUN(_putenv_r,(struct _reent *, char *__string));
 _PTR _EXFUN(_reallocf_r,(struct _reent *, _PTR, size_t));
@@ -187,12 +195,18 @@
        _EXFUN(_seed48_r,(struct _reent *, unsigned short [3]));
 _VOID  _EXFUN(srand48,(long));
 _VOID  _EXFUN(_srand48_r,(struct _reent *, long));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(atoll,(const char *__nptr));
+#endif
+#ifndef __STRICT_ANSI__
 long long _EXFUN(_atoll_r,(struct _reent *, const char *__nptr));
-long long _EXFUN(llabs,(long long));
-lldiv_t _EXFUN(lldiv,(long long __numer, long long __denom));
 #endif /* ! __STRICT_ANSI__ */
 #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) ||
(__cplusplus >= 201103L)
+long long _EXFUN(llabs,(long long));
+lldiv_t _EXFUN(lldiv,(long long __numer, long long __denom));
 long long _EXFUN(strtoll,(const char *__restrict __n, char
**__restrict __end_PTR, int __base));
 #endif
 #ifndef __STRICT_ANSI__
@@ -233,7 +247,6 @@
 #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) ||
(__cplusplus >= 201103L)
 extern long double strtold (const char *__restrict, char **__restrict);
 #endif
-extern long double wcstold (const wchar_t *, wchar_t **);
 #endif /* _LDBL_EQ_DBL */

 _END_STD_C
Index: newlib/libc/include/wchar.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/wchar.h,v
retrieving revision 1.33
diff -u -r1.33 wchar.h
--- newlib/libc/include/wchar.h 26 Nov 2013 17:20:59 -0000      1.33
+++ newlib/libc/include/wchar.h 22 Dec 2013 21:39:51 -0000
@@ -25,19 +25,30 @@
 #endif

 #ifndef WCHAR_MIN
-#define WCHAR_MIN 0
+#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 0x7fffffffu
+#define WCHAR_MAX (0x7fffffff + L'\0')
 #endif
 #endif

 _BEGIN_STD_C

+/* As in stdio.h, <sys/reent.h> defines __FILE. */
+typedef __FILE FILE;
+
 /* As required by POSIX.1-2008, declare tm as incomplete type.
    The actual definition is in time.h. */
 struct tm;
@@ -130,6 +141,10 @@
 long long _EXFUN(_wcstoll_r, (struct _reent *, const wchar_t *,
wchar_t **, int));
 unsigned long _EXFUN(_wcstoul_r, (struct _reent *, const wchar_t *,
wchar_t **, int));
 unsigned long long _EXFUN(_wcstoull_r, (struct _reent *, const
wchar_t *, wchar_t **, int));
+/* On platforms where long double equals double.  */
+#ifdef _LDBL_EQ_DBL
+long double _EXFUN(wcstold, (const wchar_t *, wchar_t **));
+#endif /* _LDBL_EQ_DBL */

 wint_t _EXFUN(fgetwc, (__FILE *));
 wchar_t *_EXFUN(fgetws, (wchar_t *__restrict, int, __FILE *__restrict));

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

[Jeff Johnston]

----- Original Message -----
> From: "JF Bastien" <jfb@chromium.org>
> To: "Jeff Johnston" <jjohnstn@redhat.com>
> Cc: "Craig Howland" <howland@lgsinnovations.com>, newlib@sourceware.org
> Sent: Friday, December 20, 2013 3:36:22 PM
> Subject: Re: [PATCH] Update newlib so that it passes libc++'s tests
> 
> > As mentioned, if the libc++ test passes with an incremental fix, then I am
> > fine
> > with it.  If it does not fix the libc++ test, then there is no impetus to
> > get a
> > partial fix in now and we can figure out a more correct solution.
> >
> > So, can you put together a patch that fixes the libc++ test, does not touch
> > stdint.h and is incrementally better for wchar.h?
> 
> I'm currently traveling so testing things isn't as easy as it should be.
> 
> IIRC the relevant test is test/depr/depr.c.headers/stdint_h.pass.cpp:
> 
>     // WCHAR_MIN
>     assert(WCHAR_MIN == std::numeric_limits<wchar_t>::min());
> 
>     // WCHAR_MAX
>     assert(WCHAR_MAX == std::numeric_limits<wchar_t>::max());
> 
> Many other tests from libc++'s test suite will pass with an
> incremental fix, so it could still be a viable option, but I think
> this particular test won't pass.
> 

Ok.  I will delay the snapshot until you resubmit the patch.  It passes additional
tests from libc++ so it is a step forward and we might as well make it part of the
snapshot.

I assume you will have this done by Monday.

-- Jeff J.

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

[JF Bastien]

> As mentioned, if the libc++ test passes with an incremental fix, then I am fine
> with it.  If it does not fix the libc++ test, then there is no impetus to get a
> partial fix in now and we can figure out a more correct solution.
>
> So, can you put together a patch that fixes the libc++ test, does not touch
> stdint.h and is incrementally better for wchar.h?

I'm currently traveling so testing things isn't as easy as it should be.

IIRC the relevant test is test/depr/depr.c.headers/stdint_h.pass.cpp:

    // WCHAR_MIN
    assert(WCHAR_MIN == std::numeric_limits<wchar_t>::min());

    // WCHAR_MAX
    assert(WCHAR_MAX == std::numeric_limits<wchar_t>::max());

Many other tests from libc++'s test suite will pass with an
incremental fix, so it could still be a viable option, but I think
this particular test won't pass.

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

[Jeff Johnston]

----- Original Message -----
> From: "JF Bastien" <jfb@chromium.org>
> To: "Craig Howland" <howland@lgsinnovations.com>
> Cc: newlib@sourceware.org, "Jeff Johnston" <jjohnstn@redhat.com>
> Sent: Friday, December 20, 2013 2:31:46 PM
> Subject: 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.
> 
> Either is fine with me, let me know what to do.
> 
> 
> > No, I was referring to the breakage of making the assumption when you don't
> > know.  (I was assuming the fix that Joseph pointed out.) The idea was to
> > apply the patch now only to wchar.h--an improvement over what is there now,
> > but still with the issue of a possibly-incorrect fallback value--but to not
> > make the addition to stdint.h.  At a future time, do the config mess and
> > then add to stdint.h.  This is just a thought to avoid introducing an issue
> > to stdint.h.
> > If this does not achieve the goal of fixing the libc++ test, then I tend to
> > agree with Jeff as to it's being an improvement worth doing, even if it
> > could use a (complicated) cleanup.
> 
> I see. So if I modified my patch to only change the WCHAR_* value for
> wchar.h and not stdint.h then you think we'd be good to go?
> 

I believe that is what he is saying.

> I also think a partial fix that's incrementally more correct is better
> than none at all, but I also want to newlib folks to agree that my
> change is indeed good!
> 

As mentioned, if the libc++ test passes with an incremental fix, then I am fine 
with it.  If it does not fix the libc++ test, then there is no impetus to get a
partial fix in now and we can figure out a more correct solution.

So, can you put together a patch that fixes the libc++ test, does not touch
stdint.h and is incrementally better for wchar.h?

-- Jeff J.

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

[JF Bastien]

>> 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.

Either is fine with me, let me know what to do.


> No, I was referring to the breakage of making the assumption when you don't
> know.  (I was assuming the fix that Joseph pointed out.) The idea was to
> apply the patch now only to wchar.h--an improvement over what is there now,
> but still with the issue of a possibly-incorrect fallback value--but to not
> make the addition to stdint.h.  At a future time, do the config mess and
> then add to stdint.h.  This is just a thought to avoid introducing an issue
> to stdint.h.
> If this does not achieve the goal of fixing the libc++ test, then I tend to
> agree with Jeff as to it's being an improvement worth doing, even if it
> could use a (complicated) cleanup.

I see. So if I modified my patch to only change the WCHAR_* value for
wchar.h and not stdint.h then you think we'd be good to go?

I also think a partial fix that's incrementally more correct is better
than none at all, but I also want to newlib folks to agree that my
change is indeed good!

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

[Craig Howland]

On 12/20/2013 01:43 PM, Jeff Johnston wrote:
> 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).
> ...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.
No, I was referring to the breakage of making the assumption when you don't 
know.  (I was assuming the fix that Joseph pointed out.) The idea was to apply 
the patch now only to wchar.h--an improvement over what is there now, but still 
with the issue of a possibly-incorrect fallback value--but to not make the 
addition to stdint.h.  At a future time, do the config mess and then add to 
stdint.h.  This is just a thought to avoid introducing an issue to stdint.h.
If this does not achieve the goal of fixing the libc++ test, then I tend to 
agree with Jeff as to it's being an improvement worth doing, even if it could 
use a (complicated) cleanup.
>
> 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

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

[Jeff Johnston]

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

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

[JF Bastien]

> 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

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

[Craig Howland]

On 12/18/2013 04:53 PM, JF Bastien wrote:
>
>
> Thanks for pointing this out, I wasn't aware of this latest glibc fix.
> Here's an updated definition (for both stdint.h and wchar.h). If it
> looks good I'll update the patch, assuming the rest of the ongoing
> discussion doesn't change this snippet further. To summarize other
> discussions, the code first relies on the compiler's own defines
> (__WCHAR_{MIN,MAX}__) and stdint.h/wchar.h includes (which could
> define WCHAR_{MIN,MAX}) to do the right thing. If that fails then
> AFAICT we're stuck with making an educated guess as to what the
> "right" value is, and in some cases that guess will necessarily be
> wrong because we can't use casts. Newlib's current guess (before my
> patch) is 32-bits, so I decided to stick to that and I don't think
> going with 16-bits is any better (it's also wrong in some cases, but
> now it's also different from what previous newlib versions used to
> guess!).
>
> I'm of course open to suggestions here, but I'm not seeing a better
> solution and hope someone else sees one.
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).
>
> #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 (0x7fffffffu + L'\0')
> #endif
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.

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

[Joseph S. Myers]

On Wed, 18 Dec 2013, JF Bastien wrote:

> #elif defined(__WCHAR_UNSIGNED__) || (L'\0' - 1 > 0)
> #define WCHAR_MAX (0xffffffffu + L'\0')
> #else
> #define WCHAR_MAX (0x7fffffffu + L'\0')

You don't want the "u" suffix in this #else case (signed wchar_t).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[JF Bastien]

> A value of 0 as WCHAR_MIN in the unsigned case has the wrong type if
> wchar_t promotes to unsigned int / unsigned long (as opposed to, say, if
> it's unsigned short promoting to signed int).  glibc (2.18 and later) uses
> (L'\0' + 0) (if __WCHAR_MIN__ isn't predefined) in the unsigned case to
> get the correct promoted version of wchar_t, and similar constructs
> involving + L'\0' for WCHAR_MAX to get the right type in those cases as
> well.
>
> In general, you need to make sure these constants have the right type,
> being the promoted version of the type to which the macros refer,
> including int/long differences even when those have the same
> representation and alignment - and, for C++, distinguishing the distinct
> wchar_t type from the type to which it promotes (the latter being the
> right type for such constants) - not just the right value.  In #if
> expressions they need the same value and signedness as in normal C/C++
> code (this means that (L'\0' - 1) is not a correct expression for
> WCHAR_MAX in the unsigned case because in #if expressions it would
> evaluate to UINTMAX_MAX).


Thanks for pointing this out, I wasn't aware of this latest glibc fix.
Here's an updated definition (for both stdint.h and wchar.h). If it
looks good I'll update the patch, assuming the rest of the ongoing
discussion doesn't change this snippet further. To summarize other
discussions, the code first relies on the compiler's own defines
(__WCHAR_{MIN,MAX}__) and stdint.h/wchar.h includes (which could
define WCHAR_{MIN,MAX}) to do the right thing. If that fails then
AFAICT we're stuck with making an educated guess as to what the
"right" value is, and in some cases that guess will necessarily be
wrong because we can't use casts. Newlib's current guess (before my
patch) is 32-bits, so I decided to stick to that and I don't think
going with 16-bits is any better (it's also wrong in some cases, but
now it's also different from what previous newlib versions used to
guess!).

I'm of course open to suggestions here, but I'm not seeing a better
solution and hope someone else sees one.

#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 (0x7fffffffu + L'\0')
#endif

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

[JF Bastien]

> Recent GCC have built-in defines:
>
> #define __WCHAR_TYPE__ long int
> #define __WCHAR_MAX__ 2147483647L
> #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
>
> Maybe we can use them if available.  Does LLVM also provide such built-in
> defines?

My fix uses __WCHAR_MAX__ and __WCHAR_MIN__ if available. Yes, both
GCC and LLVM have them (rather, LLVM has __WCHAR_MAX__,
__WCHAR_TYPE__, __WCHAR_WIDTH__ and __WCHAR_UNSIGNED__, and its
stdint.h has WCHAR_MAX and WCHAR_MIN definitions based on these).

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

[Craig Howland]

On 12/18/2013 04:14 PM, Steven Abner wrote:
> 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
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.
Craig

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

[JF Bastien]

> > >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.

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

[Steven Abner]

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

On Dec 18 21:58, 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.
                 ^^^^^^^^
                designe*r*


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Steven Abner]

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 ?
 I ask because my understanding was it was a "keyword" like int and
long that is set by a compiler, based on guessing system's encoding schemes.
Supposedly from C90: "an integral type whose range of values can represent
distinct codes for all members of the largest extended character set specified
among the supported locales". And that the wchar_t functions are functions
that accept multibyte encodings up to 32bits, since I personally dont know
any 64bit encodings. But again a system that uses Latin1 encodings defines
as an 8bit wchar_t.
Sorry about interruption, but important to me as a code designer.
Steve

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Craig Howland]

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.  ("The expression that controls conditional inclusion shall be an 
integer constant expression except that: it shall not contain a cast; ...")
      I tried it with GCC 4.4.7 and it works, but since the standard expressly 
forbids it, it probably is not good to do.
                 Craig

#define WCHAR_MAX ((wchar_t)-1)

#if WCHAR_MAX == -1
   #include <stdint.h>
  #else
   #error "!-1"
#endif

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

On Dec 16 16:54, JF Bastien wrote:
> Index: newlib/libc/include/stdint.h
> ===================================================================
> RCS file: /cvs/src/src/newlib/libc/include/stdint.h,v
> retrieving revision 1.17
> diff -u -r1.17 stdint.h
> --- newlib/libc/include/stdint.h	3 Dec 2013 16:04:41 -0000	1.17
> +++ newlib/libc/include/stdint.h	17 Dec 2013 00:40:00 -0000
> @@ -423,23 +423,42 @@
>  #endif
>  #define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
>  
> +#ifndef WCHAR_MIN
> +#ifdef __WCHAR_MIN__
> +#define WCHAR_MIN __WCHAR_MIN__
> +#elif defined(__WCHAR_UNSIGNED__)
> +#define WCHAR_MIN 0
> +#else
> +#define WCHAR_MIN (-0x7fffffff - 1)
> +#endif
> +#endif

This...

> +#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)

etc.

> ===================================================================
> RCS file: /cvs/src/src/newlib/libc/include/wchar.h,v
> retrieving revision 1.33
> diff -u -r1.33 wchar.h
> --- newlib/libc/include/wchar.h	26 Nov 2013 17:20:59 -0000	1.33
> +++ newlib/libc/include/wchar.h	17 Dec 2013 00:40:00 -0000
> @@ -25,12 +25,20 @@
>  #endif
>  
>  #ifndef WCHAR_MIN
> +#ifdef __WCHAR_MIN__
> +#define WCHAR_MIN __WCHAR_MIN__
> +#elif defined(__WCHAR_UNSIGNED__)
>  #define WCHAR_MIN 0
> +#else
> +#define WCHAR_MIN (-0x7fffffff - 1)
> +#endif
>  #endif
>  
>  #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
> @@ -38,6 +46,9 @@

Same here in wchar.h.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Sebastian Huber]

On 2013-12-17 01:54, JF Bastien wrote:
> Fix issues that LLVM's libc++ test suite finds when setting newlib as
> the C library:
>    - limits.h: define LLONG_MIN, LLONG_MAX and ULLONG_MAX for C++11 too.
>    - stdint.h: define WCHAR_MIN and WCHAR_MAX according to
> __WCHAR_UNSIGNED__ if it is provided, and correct the limit when
> unsigned (to 32 all-1 bits, not 31). Make sure stdint.h and wchar.h
> are in sync.
>    - stdint.h: similarly for WINT_MIN and WINT_MAX according to
> __WINT_UNSIGNED__.
>    - stdlib.h: define struct lldiv_t, _Exit, atoll, llabs and lldiv for
> C99 and C++11.
>    - stdlib.h: move wcstold to wchar.h.
>    - wchar.h: define WCHAR_MIN and WCHAR_MAX according to
> __WCHAR_UNSIGNED__ if it is provided, and correct the limit when
> unsigned (to 32 all-1 bits, not 31). Make sure stdint.h and wchar.h
> are in sync.
>    - wchar.h: define file as in stdio.h.
>    - stdlib.h: move wcstold from stdlib.h.
>
> Note that libc++ also needs changes to adapt to newlib's C flavor, I'm
> sending a separate patch to thecfe-commits@cs.uiuc.edu  mailing list.

Recent GCC have built-in defines:

#define __WCHAR_TYPE__ long int
#define __WCHAR_MAX__ 2147483647L
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)

Maybe we can use them if available.  Does LLVM also provide such built-in defines?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

[JF Bastien]

No rush on my side, I can wait until after the release. I'll fix the
*CHAR* issues Joseph raised and send another patch later this week.

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

[Joseph S. Myers]

On Mon, 16 Dec 2013, JF Bastien wrote:

>   - stdint.h: define WCHAR_MIN and WCHAR_MAX according to
> __WCHAR_UNSIGNED__ if it is provided, and correct the limit when
> unsigned (to 32 all-1 bits, not 31). Make sure stdint.h and wchar.h
> are in sync.

A value of 0 as WCHAR_MIN in the unsigned case has the wrong type if 
wchar_t promotes to unsigned int / unsigned long (as opposed to, say, if 
it's unsigned short promoting to signed int).  glibc (2.18 and later) uses 
(L'\0' + 0) (if __WCHAR_MIN__ isn't predefined) in the unsigned case to 
get the correct promoted version of wchar_t, and similar constructs 
involving + L'\0' for WCHAR_MAX to get the right type in those cases as 
well.

In general, you need to make sure these constants have the right type, 
being the promoted version of the type to which the macros refer, 
including int/long differences even when those have the same 
representation and alignment - and, for C++, distinguishing the distinct 
wchar_t type from the type to which it promotes (the latter being the 
right type for such constants) - not just the right value.  In #if 
expressions they need the same value and signedness as in normal C/C++ 
code (this means that (L'\0' - 1) is not a correct expression for 
WCHAR_MAX in the unsigned case because in #if expressions it would 
evaluate to UINTMAX_MAX).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[JF Bastien]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

Fix issues that LLVM's libc++ test suite finds when setting newlib as
the C library:
  - limits.h: define LLONG_MIN, LLONG_MAX and ULLONG_MAX for C++11 too.
  - stdint.h: define WCHAR_MIN and WCHAR_MAX according to
__WCHAR_UNSIGNED__ if it is provided, and correct the limit when
unsigned (to 32 all-1 bits, not 31). Make sure stdint.h and wchar.h
are in sync.
  - stdint.h: similarly for WINT_MIN and WINT_MAX according to
__WINT_UNSIGNED__.
  - stdlib.h: define struct lldiv_t, _Exit, atoll, llabs and lldiv for
C99 and C++11.
  - stdlib.h: move wcstold to wchar.h.
  - wchar.h: define WCHAR_MIN and WCHAR_MAX according to
__WCHAR_UNSIGNED__ if it is provided, and correct the limit when
unsigned (to 32 all-1 bits, not 31). Make sure stdint.h and wchar.h
are in sync.
  - wchar.h: define file as in stdio.h.
  - stdlib.h: move wcstold from stdlib.h.

Note that libc++ also needs changes to adapt to newlib's C flavor, I'm
sending a separate patch to the cfe-commits@cs.uiuc.edu mailing list.

[-- Attachment #2: libc++.patch --]
[-- Type: text/x-patch, Size: 6226 bytes --]

Index: newlib/libc/include/limits.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/limits.h,v
retrieving revision 1.3
diff -u -r1.3 limits.h
--- newlib/libc/include/limits.h	31 Oct 2008 21:03:41 -0000	1.3
+++ newlib/libc/include/limits.h	17 Dec 2013 00:40:00 -0000
@@ -96,7 +96,8 @@
 #    define __LONG_LONG_MAX__ 9223372036854775807LL
 #   endif
 
-#   if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+#   if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) ||   \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 /* Minimum and maximum values a `signed long long int' can hold.  */
 #    undef LLONG_MIN
 #    define LLONG_MIN (-LLONG_MAX-1)
@@ -143,4 +144,3 @@
 #ifndef PATH_MAX
 #define PATH_MAX	4096
 #endif
-
Index: newlib/libc/include/stdint.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/stdint.h,v
retrieving revision 1.17
diff -u -r1.17 stdint.h
--- newlib/libc/include/stdint.h	3 Dec 2013 16:04:41 -0000	1.17
+++ newlib/libc/include/stdint.h	17 Dec 2013 00:40:00 -0000
@@ -423,23 +423,42 @@
 #endif
 #define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
 
+#ifndef WCHAR_MIN
+#ifdef __WCHAR_MIN__
+#define WCHAR_MIN __WCHAR_MIN__
+#elif defined(__WCHAR_UNSIGNED__)
+#define WCHAR_MIN 0
+#else
+#define WCHAR_MIN (-0x7fffffff - 1)
+#endif
+#endif
+
+#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
-#ifdef __WCHAR_MIN__
-#define WCHAR_MIN __WCHAR_MIN__
 #endif
 
 /* wint_t is unsigned int on almost all GCC targets.  */
 #ifdef __WINT_MAX__
 #define WINT_MAX __WINT_MAX__
 #else
+#elif defined(__WINT_UNSIGNED__)
 #define WINT_MAX (__STDINT_EXP(INT_MAX) * 2U + 1U)
+#else
+#define WINT_MAX __STDINT_EXP(INT_MAX)
 #endif
 #ifdef __WINT_MIN__
 #define WINT_MIN __WINT_MIN__
 #else
+#elif defined(__WINT_UNSIGNED__)
 #define WINT_MIN 0U
+#else
+#define WINT_MIN (-WINT_MAX - 1)
 #endif
 
 /** Macros for minimum-width integer constant expressions */
Index: newlib/libc/include/stdlib.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/stdlib.h,v
retrieving revision 1.48
diff -u -r1.48 stdlib.h
--- newlib/libc/include/stdlib.h	20 Nov 2013 09:46:39 -0000	1.48
+++ newlib/libc/include/stdlib.h	17 Dec 2013 00:40:00 -0000
@@ -39,7 +39,9 @@
   long rem; /* remainder */
 } ldiv_t;
 
-#ifndef __STRICT_ANSI__
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 typedef struct
 {
   long long int quot; /* quotient */
@@ -149,7 +151,13 @@
 char *  _EXFUN(l64a,(long __input));
 char *  _EXFUN(_l64a_r,(struct _reent *,long __input));
 int	_EXFUN(on_exit,(_VOID (*__func)(int, _PTR),_PTR __arg));
-_VOID	_EXFUN(_Exit,(int __status) _ATTRIBUTE ((noreturn)));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
+_VOID  _EXFUN(_Exit,(int __status) _ATTRIBUTE ((noreturn)));
+#endif
+#ifndef __STRICT_ANSI__
 int	_EXFUN(putenv,(char *__string));
 int	_EXFUN(_putenv_r,(struct _reent *, char *__string));
 _PTR	_EXFUN(_reallocf_r,(struct _reent *, _PTR, size_t));
@@ -187,12 +195,18 @@
        _EXFUN(_seed48_r,(struct _reent *, unsigned short [3]));
 _VOID  _EXFUN(srand48,(long));
 _VOID  _EXFUN(_srand48_r,(struct _reent *, long));
+#endif /* ! __STRICT_ANSI__ */
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 long long _EXFUN(atoll,(const char *__nptr));
+#endif
+#ifndef __STRICT_ANSI__
 long long _EXFUN(_atoll_r,(struct _reent *, const char *__nptr));
-long long _EXFUN(llabs,(long long));
-lldiv_t	_EXFUN(lldiv,(long long __numer, long long __denom));
 #endif /* ! __STRICT_ANSI__ */
 #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
+long long _EXFUN(llabs,(long long));
+lldiv_t	_EXFUN(lldiv,(long long __numer, long long __denom));
 long long _EXFUN(strtoll,(const char *__restrict __n, char **__restrict __end_PTR, int __base));
 #endif
 #ifndef __STRICT_ANSI__
@@ -233,7 +247,6 @@
 #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L)
 extern long double strtold (const char *__restrict, char **__restrict);
 #endif
-extern long double wcstold (const wchar_t *, wchar_t **);
 #endif /* _LDBL_EQ_DBL */
 
 _END_STD_C
Index: newlib/libc/include/wchar.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/wchar.h,v
retrieving revision 1.33
diff -u -r1.33 wchar.h
--- newlib/libc/include/wchar.h	26 Nov 2013 17:20:59 -0000	1.33
+++ newlib/libc/include/wchar.h	17 Dec 2013 00:40:00 -0000
@@ -25,12 +25,20 @@
 #endif
 
 #ifndef WCHAR_MIN
+#ifdef __WCHAR_MIN__
+#define WCHAR_MIN __WCHAR_MIN__
+#elif defined(__WCHAR_UNSIGNED__)
 #define WCHAR_MIN 0
+#else
+#define WCHAR_MIN (-0x7fffffff - 1)
+#endif
 #endif
 
 #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
@@ -38,6 +46,9 @@
 
 _BEGIN_STD_C
 
+/* As in stdio.h, <sys/reent.h> defines __FILE. */
+typedef __FILE FILE;
+
 /* As required by POSIX.1-2008, declare tm as incomplete type.
    The actual definition is in time.h. */
 struct tm;
@@ -130,6 +141,10 @@
 long long _EXFUN(_wcstoll_r, (struct _reent *, const wchar_t *, wchar_t **, int));
 unsigned long _EXFUN(_wcstoul_r, (struct _reent *, const wchar_t *, wchar_t **, int));
 unsigned long long _EXFUN(_wcstoull_r, (struct _reent *, const wchar_t *, wchar_t **, int));
+/* On platforms where long double equals double.  */
+#ifdef _LDBL_EQ_DBL
+long double _EXFUN(wcstold, (const wchar_t *, wchar_t **));
+#endif /* _LDBL_EQ_DBL */
 
 wint_t _EXFUN(fgetwc, (__FILE *));
 wchar_t *_EXFUN(fgetws, (wchar_t *__restrict, int, __FILE *__restrict));