Re: bug#8675: error: token @ is not valid in preprocessor expressions

2011-05-19 Thread Paul Eggert
If the previous Makefile.in was not based on gnulib 2011-04-03 or newer, we need to do nothing; the problem is already fixed. I am not sure what version of gnulib my Makefile was based on. The previous Emacs trunk commit (i.e., the commit before the one that caused you a problem) was based

Re: proposed new module intprops-test

2011-05-19 Thread Paul Eggert
Thanks for testing that. I replicated the problem on Solaris 10 with Sun C 5.11 and Solaris 8 with Sun C 5.8. The following patches fixed it for me. I can't easily test HP-UX and IRIX but I tried to fix all the problems I could deduce remotely. Apparently these compilers mishandle constants

Re: proposed new module intprops-test

2011-05-19 Thread Bruno Haible
Hi Paul, 2011-05-19 Paul Eggert egg...@cs.ucla.edu + intprops: work around C compiler bugs + * lib/intprops.h (INT_MULTIPLY_RANGE_OVERFLOW): Work around compiler + bug in Sun C 5.11 2010/08/13 and other compilers; see +

[PATCH] strerror: enforce POSIX ruling on strerror(0)

2011-05-19 Thread Eric Blake
http://austingroupbugs.net/view.php?id=382 requires that strerror(0) succeed, but FreeBSD reports Unknown error: 0 and fails with EINVAL. * m4/strerror.m4 (gl_FUNC_STRERROR_SEPARATE): Expose BSD bug. * m4/strerror_r.m4 (gl_FUNC_STRERROR_R): Likewise. * lib/strerror_r.c (rpl_strerror_r): Work

[PATCH] strerror: relax test for Solaris

2011-05-19 Thread Eric Blake
Solaris returns Error 0 for 0 vs. Unknown error for -1; while that does not quite have the positive connotation that POSIX recommends, it is distinct enough that we do not need to replace the native strerror just to pick a better string. The test is really trying to reject implementations that

Re: strerror_r on mingw

2011-05-19 Thread Bruno Haible
2011-05-18 Bruno Haible br...@clisp.org strerror_r: Avoid clobbering the strerror buffer when possible. * lib/strerror_r.c (strerror_r): Merge the three implementations. Handle gnulib defined errno values here. When strerror() returns NULL or an empty string,

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 does

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

[PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Eric Blake
* lib/strerror_r.c (rpl_strerror_r): Cygwin now has __xpg_strerror_r, use it. Signed-off-by: Eric Blake ebl...@redhat.com --- Without this, recent test improvements were exposing failures of gnulib's replacement on cygwin. ChangeLog|6 ++ lib/strerror_r.c | 12 ++-- 2

Re: perror bug

2011-05-19 Thread Bruno Haible
On 2011-14-03 I wrote in http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00117.html: 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

[PATCH] strerror_r: guarantee unchanged errno

2011-05-19 Thread Eric Blake
POSIX guarantees that strerror doesn't change errno on success, and since we implement strerror by using strerror_r, it makes sense to make the same guarantee for strerror_r (rather, going one step further to say that sterror_r does not corrupt errno even on failure, since it returns an error

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Bruno Haible
Eric Blake wrote: --- a/lib/strerror_r.c +++ b/lib/strerror_r.c @@ -34,7 +34,11 @@ # endif -#if HAVE_DECL_STRERROR_R !(__GLIBC__ = 2 || defined __UCLIBC__) +#if (__GLIBC__ = 2 || defined __UCLIBC__ || defined __CYGWIN__) HAVE___XPG_STRERROR_R /* glibc = 2.3.4, cygwin = 1.7.9 */ +

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Bruno Haible
Hi Eric, Without this, recent test improvements were exposing failures of gnulib's replacement on cygwin. Which failures were this? If I understand it correctly, a gnulib strerror_r replacement that does not use __xpg_strerror_r on Cygwin 1.7.9 should be identical to the one built on Cygwin =

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Eric Blake
On 05/19/2011 02:12 PM, Bruno Haible wrote: Hi Eric, Without this, recent test improvements were exposing failures of gnulib's replacement on cygwin. Which failures were this? If I understand it correctly, a gnulib strerror_r replacement that does not use __xpg_strerror_r on Cygwin 1.7.9

Re: [PATCH] strerror_r: guarantee unchanged errno

2011-05-19 Thread Bruno Haible
Hi Eric, * lib/strerror_r.c (strerror_r): Guarantee unchanged errno. ... preserving errno is important when replacing sterror_r on platforms that return -1. Makes sense, yes. --- a/lib/strerror.c +++ b/lib/strerror.c @@ -50,6 +50,7 @@ strerror (int n) static char const fmt[] =

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 (errnum) !

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Bruno Haible
Hi Eric, in the process of adding __xpg_sterror_r, the original strerror_r was fixed to align more closely to glibc behavior. Thus, it was changed so that strerror_r(EACCES, buf, 2) no longer overwrites buf with a (truncated) message to buf, so the caller instead has to manually copy the

gnulib translations (was: strerror translations)

2011-05-19 Thread Bruno Haible
Hi Eric, Should we be marking all of these msg strings for translation? It would be a bit disconcerting to have some, but not all, strerror messages translated on a platform where we are augmenting the existing system errno values. If this is done, the translators should be made aware that

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Eric Blake
On 05/19/2011 02:51 PM, Bruno Haible wrote: in the process of adding __xpg_sterror_r, the original strerror_r was fixed to align more closely to glibc behavior. Thus, it was changed so that strerror_r(EACCES, buf, 2) no longer overwrites buf with a (truncated) message to buf, so the caller

Re: [PATCH] strerror_r: fix on newer cygwin

2011-05-19 Thread Bruno Haible
Eric Blake wrote: More accurately: The change in strerror_r behavior was in 1.7.8 (which also tried to introduce __xpg_strerror_r), but a bug in the headers vs. export table ended up with a link failure for __xpg_strerror_r: http://cygwin.com/ml/cygwin/2011-03/msg00247.html In = 1.7.7,

Re: proposed new module intprops-test

2011-05-19 Thread Paul Eggert
On 05/19/11 06:07, Bruno Haible wrote: Thanks, this patch fixed the errors on OSF/1 5.1 and reduced the errors on Solaris 9 to only one:... Yes, thanks, I've committed something which I hope fixes that; see below. This part of the patch has no effect on HP-UX, IRIX, and neither on OSF/1 and