Re: circular dependency [was: perror bug]

2011-05-20 Thread Eric Blake
On 05/20/2011 12:42 PM, Bruno Haible wrote: > Hi Eric, > >> This change means that now strerror depends on strerror_r-posix, and >> strerror_r-posix depends on strerror. Is that circular dependency okay >> for gnulib-tool? > > Yes, gnulib-tool supports circular dependencies, even with > --condit

Re: circular dependency [was: perror bug]

2011-05-20 Thread Bruno Haible
Hi Eric, > This change means that now strerror depends on strerror_r-posix, and > strerror_r-posix depends on strerror. Is that circular dependency okay > for gnulib-tool? Yes, gnulib-tool supports circular dependencies, even with --conditional-dependencies. But the circular dependency was not

circular dependency [was: perror bug]

2011-05-20 Thread Eric Blake
On 05/18/2011 09:27 PM, Bruno Haible wrote: >> 1) The strerror_r replacement, when EXTEND_STRERROR_R is defined, >> clobbers the strerror function's buffer, which it shouldn't. > > Here comes the fix for 1). Tested on > > --- modules/strerror Thu May 19 04:13:54 2011 > *** > *

strerror translations [was: perror bug]

2011-05-19 Thread Eric Blake
On 05/18/2011 09:27 PM, Bruno Haible wrote: > int > strerror_r (int errnum, char *buf, size_t buflen) > ! #undef strerror_r > { > ! #if EXTEND_STRERROR_R > ! { > ! char const *msg = NULL; > ! /* These error messages are taken from glibc/sysdeps/gnu/errlist.c. */ > ! switch (err

Re: perror bug

2011-05-19 Thread Bruno Haible
On 2011-14-03 I wrote in : > 2) The perror replacement uses strerror, thus clobbering the strerror > buffer. > 3) On Cygwin, perror clobbers the strerror buffer. > > The fix for 2) should be to change lib/perror.c to call

Re: perror bug

2011-05-19 Thread Bruno Haible
> +# elif defined __sgi || (defined __sun && !defined _LP64) /* IRIX, Solaris > <= 9 32-bit */ > + > +    /* For a valid error number, the system's strerror() function returns > +       a pointer to a not copied string, not to a buffer.  */ Just for reference: How to find out whether a closed-sou

Re: perror bug

2011-05-19 Thread Bruno Haible
> >   1) The strerror_r replacement, when EXTEND_STRERROR_R is defined, > >      clobbers the strerror function's buffer, which it shouldn't. Here's a followup that tries harder to clobber the strerror function's buffer. It still is not possible on Solaris <= 9 in 64-bit mode, because that libc do

Re: perror bug

2011-05-18 Thread Bruno Haible
On 2011-14-03 I wrote in : > With gnulib, there are three problems > in toto: >   1) The strerror_r replacement, when EXTEND_STRERROR_R is defined, >      clobbers the strerror function's buffer, which it shouldn't. >   2) The perr

Re: perror bug

2011-03-14 Thread Bruno Haible
Eric Blake wrote on 2011-02-10: > POSIX requires that this program have an identical first and last line: > > #include > #include > #include > int main (void) { > char *err = strerror(1000); > printf ("%s\n", err); > errno = 2000; > perror ("hi"); > printf ("%s\n", err); > return 0;

Re: perror bug

2011-02-09 Thread Eric Blake
On 02/09/2011 05:48 PM, Eric Blake wrote: > POSIX requires that this program have an identical first and last line: > > #include > #include > #include > int main (void) { > char *err = strerror(1000); > printf ("%s\n", err); > errno = 2000; > perror ("hi"); > printf ("%s\n", err); >

perror bug

2011-02-09 Thread Eric Blake
POSIX requires that this program have an identical first and last line: #include #include #include int main (void) { char *err = strerror(1000); printf ("%s\n", err); errno = 2000; perror ("hi"); printf ("%s\n", err); return 0; } but on cygwin 1.7.7, the perror() corrupts the buffe