[PATCH] Change strerror_r definition for cygwin
Fri Aug 26 11:49:00 GMT 2005
On Aug 26 11:27, Ralf Corsepius wrote:
> 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:
> int *strerror_r(int, char *, size_t);
> 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.
Yes, this looks definitely like a bug in the SUSv3 specification. Did
you report it to the Open Group?
Cygwin Project Co-Leader
Red Hat, Inc.
More information about the Newlib