This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Change strerror_r definition for cygwin
On Fri, 2005-08-26 at 10:43 +0200, Corinna Vinschen wrote:
> On Aug 25 22:18, Christopher Faylor wrote:
> > On Thu, Aug 25, 2005 at 07:03:42PM -0400, Christopher Faylor wrote:
> > >It seems like newlib's strerror_r implementation is not compliant with
> > >standards. We need to have strerror_r return an integer for cygwin so
> > >I've made the change below.
> > >
> > >OTOH, if this change should be the default, let me know and I'll be
> > >happy to change libc/string/strerror_r.c .
> >
> > Sorry about that. Apparently it isn't that simple. There are two
> > differing implementations of strerror_r and newlib is emulating the
> > default linux version.
>
> But the Linux man page has this to say:
>
> "CONFORMING TO
> SVID 3, POSIX, BSD 4.3, ISO/IEC 9899:1990 (C89).
>
> strerror_r() with prototype as given above is specified by SUSv3, [...]
> An incompatible function, with prototype
>
> char *strerror_r(int errnum, char *buf, size_t n);
>
> is a GNU extension used by glibc (since 2.0), and must be regarded as
> obsolete in view of SUSv3."
>
> I like the sound of the word "obsolete".
So do I, but I am a bit confused by directly looking at SUSv3:
http://www.opengroup.org/onlinepubs/009695399/basedefs/string.h.html
...
int *strerror_r(int, char *, size_t);
...
http://www.opengroup.org/onlinepubs/009695399/functions/strerror.html
...
int strerror_r(int errnum, char *strerrbuf, size_t buflen);
...
/me thinks, the former is defect in SUSv3, so I am inclined to agree
with Christopher's plan.
Ralf