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
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
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
+
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
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
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,
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
+# 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
* 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
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
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
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 */
+
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 =
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
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[] =
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)
!
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
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
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
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,
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
21 matches
Mail list logo
