gc-random fixes

Applied. /Simon >From 2fd7e9189c239ef737105bc085ace4dc80435533 Mon Sep 17 00:00:00 2001 From: Simon Josefsson <[EMAIL PROTECTED]> Date: Fri, 11 Apr 2008 09:16:11 +0200 Subject: [PATCH] Make gc_random work under Windows. Based on patch from Adam Strzelecki <[EMAIL PROTECTED]> in

glibc's snprintf can fail with ENOMEM: replacement needed

FYI, I've just reported the problem: http://bugzilla.redhat.com/441945 http://thread.gmane.org/gmane.comp.lib.glibc.alpha/13288 Quick summary: given a small buffer, say "char b[10];" with the latest upstream glibc, snprintf (b, sizeof b, fmt, 0) can fail, returning -1 with ENOMEM. The pr

Re: glibc's snprintf can fail with ENOMEM: replacement needed

Jim Meyering wrote: > FYI, I've just reported the problem: > > http://bugzilla.redhat.com/441945 > http://thread.gmane.org/gmane.comp.lib.glibc.alpha/13288 > > Quick summary: given a small buffer, say "char b[10];" with the latest > upstream glibc, snprintf (b, sizeof b, fmt, 0) can fail,

Re: gnulib git now read-only

Jim Meyering wrote: > I've fixed the permissions. Thanks. "git push" works fine now. Bruno

[PATCH] Speedup matching of ^$ and cleanup

Regex matching has an optimization where only one match is tried for a regex anchored to the beginning of the buffer. While other anchors are resolved with the fastmap, this one allows further optimization and is special cased. However, because of a bug in create_cd_newstate, ^$ would be mist

Re: m4-1.4.11: assert failure in two self tests on NetBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Thomas Klausner on 4/11/2008 12:07 AM: | Hi! | | m4-1.4.11 fails two selftests on NetBSD-4.99.48/amd64. Hi Thomas, and thanks for the report. Both of these failures are in the gnulib tests, hence I'm adding bug-gnulib. Could you please

git-merge-changelog: fix link error

The git-merge-changelog does not link on MacOS X: gcc -std=gnu99 -g -O2 -o git-merge-changelog git-merge-changelog.o libgnu.a -lm Undefined symbols: "_libintl_gettext", referenced from: _xalloc_die in libgnu.a(xalloc-die.o) _error_tail in libgnu.a(error.o) __getopt_intern

Re: m4-1.4.11: assert failure in two self tests on NetBSD

Hi Eric! Thanks for your reply. > Both of these failures are in the gnulib tests, hence I'm adding > bug-gnulib. Could you please also run 'make -k check' to see if the > M4-specific tests pass? Sure. Skipped checks were: ./109.changeword ./110.changeword ./111.changeword ./112.changeword .

Re: glibc's snprintf can fail with ENOMEM: replacement needed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 4/11/2008 4:43 AM: | 1) for float to decimal conversion, think of snprintf (NULL, "%Le", x) | or snprintf (NULL, "%Lf", x) | | At least in the first case, I don't see how the number of output bytes could | be determ

Re: Working os/2 configuratie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Elbert Pol on 4/10/2008 2:49 PM: | Hi Eric, | | I attach the check.log it fails :( I guessed it might, since Bruno's patch for EMX was preliminary. At any rate, here's the relevant gnulib portions: Killed by SIGABRT pid=0x038a ppid=0x0

Re: m4-1.4.11: assert failure in two self tests on NetBSD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Thomas Klausner on 4/11/2008 6:29 AM: |> M4-specific tests pass? | | Sure. | Skipped checks were: | ./109.changeword ./110.changeword ./111.changeword ./112.changeword | ./113.changeword ./114.changeword | All checks successful | | Lo

inline related build failures on MacOS X 10.5

On MacOS X 10.5.2, GNU cpio-2.9 and GNU tar-1.18 exhibit build failures. This is for cpio: gcc -std=gnu99 -g -O2 -o cpio copyin.o copyout.o copypass.o defer.o dstring.o global.o main.o tar.o util.o filemode.o idcache.o makepath.o userspec.o ../lib/libcpio.a -L/Users/bruno/data/local-macos

Re: stdarg: don't put compiler in gnu99 mode by default

Simon Josefsson wrote: > The problem appears > to be conflicting linker behaviour for 'extern inline' and a problem > with the Mac OS X linker. See: > > http://thread.gmane.org/gmane.network.gnutls.general/1061/focus=1136 It has to do with 'extern inline', and it has to do with MacOS X. I assume

Re: [PATCH] Speedup matching of ^$ and cleanup

Paolo Bonzini wrote: > I attach a patch for glibc (against CVS), and one for gnulib, asking for > gnulib approval, and glibc approval+commit. For patches like this one, the only requirement that gnulib has and that glibc has not, is C89 compatibility. I don't see declarations after statements in

Re: Bug in GNULIB wchar.h?

> OK to change the comment like this? Paul didn't comment or object. So I applied this. 2008-04-11 Bruno Haible <[EMAIL PROTECTED]> * lib/wchar.in.h: Tweak comment. > --- lib/wchar.in.h.orig 2008-03-31 13:05:33.0 +0200 > +++ lib/wchar.in.h2008-03-31 13:05:20.

Re: glibc's snprintf can fail with ENOMEM: replacement needed

Eric Blake wrote: > According to Bruno Haible on 4/11/2008 4:43 AM: > | 1) for float to decimal conversion, think of snprintf (NULL, "%Le", x) > | or snprintf (NULL, "%Lf", x) > | > | At least in the first case, I don't see how the number of output bytes could > | be determined without doing

Re: inline related build failures on MacOS X 10.5

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > $ gcc -v 2>&1 | tail -1 > gcc version 4.0.1 (Apple Inc. build 5465) > > It appears to be a GCC 4.0.x with some backports from the GCC 4.2 and 4.3 > development. > > For 'extern inline', this gcc generates a symbol with global visibility in > "gcc

Re: Working os/2 configuratie

Eric Blake wrote: > More failures without line numbers: > Killed by SIGFPE > FAIL: test-frexp.exe > Killed by SIGFPE > FAIL: test-frexpl.exe > Killed by SIGFPE > FAIL: test-printf-frexp.exe > Killed by SIGFPE > FAIL: test-printf-frexpl.exe > Killed by SIGFPE > FAIL: test-signbit.exe > > ... Bruno'

Re: stdarg: don't put compiler in gnu99 mode by default

Hi Bruno, Bruno Haible <[EMAIL PROTECTED]> writes: > + #ifdef __GNUC_STDC_INLINE__ > + #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ > ((__gnu_inline__)) Unfortunately that doesn't work on MacOS X because Apple's GCC (labeled "4.0") implements C99 inline semantics but 1. Does n

Re: inline related build failures on MacOS X 10.5

Ludovic Courtès wrote: > FWIW, I solved it this way in Guile, based on what GNU R does: > > > http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c Do you have information about the compilers with build numbers 5401..5464 ? Btw, when the next versio

Re: inline related build failures on MacOS X 10.5

Hi, Bruno Haible <[EMAIL PROTECTED]> writes: > Ludovic Courtès wrote: >> FWIW, I solved it this way in Guile, based on what GNU R does: >> >> >> http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c > > Do you have information about the compilers wi

Re: glibc's snprintf can fail with ENOMEM: replacement needed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> FYI, I've just reported the problem: >> >> http://bugzilla.redhat.com/441945 >> http://thread.gmane.org/gmane.comp.lib.glibc.alpha/13288 >> >> Quick summary: given a small buffer, say "char b[10];" with the latest >> upstream

Re: abort and stderr

Bruno Haible clisp.org> writes: > Yes, we need line numbers before we can do anything about it. > > > Since POSIX [1] now says that abort() *MAY* flush the stdio streams (not > *SHOULD* any more!), we need to flush it ourselves. Even POSIX 2008 states only this (remembering that fclose implies

Re: inline related build failures on MacOS X 10.5

Hello, I haven't followed the discussion at all, but: * Bruno Haible wrote on Fri, Apr 11, 2008 at 03:14:07PM CEST: > > This should ideally be solved through autoconf (let autoconf try > "-std=gnu99 -D__GNUC_STDC_INLINE__" instead of "-std=gnu99"), but since I > don't know when the next autoconf

regex_internal.h and OS/2

Based on Elbert's report: http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2447 I'm committing this. >From e9136009421f7de5d4eb9ae04b10b2c3094ce0cd Mon Sep 17 00:00:00 2001 From: Eric Blake <[EMAIL PROTECTED]> Date: Fri, 11 Apr 2008 10:22:22 -0600 Subject: [PATCH] Avoid compile failure on OS/2. *

Re: inline related build failures on MacOS X 10.5

Bruno Haible wrote: > Ludovic Courtès wrote: >> FWIW, I solved it this way in Guile, based on what GNU R does: >> >> >> http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c > > Do you have information about the compilers with build numbers 5401..5464

trim: fix compilation error

This fixes a compilation error with IRIX 6.5 cc: strdup is declared in . 2008-04-11 Bruno Haible <[EMAIL PROTECTED]> * lib/trim.c: Include . --- lib/trim.c.orig 2008-04-12 00:24:17.0 +0200 +++ lib/trim.c 2008-04-12 00:21:37.0 +0200 @@ -1,5 +1,5 @@ /* Removes leadi

Re: inline related build failures on MacOS X 10.5

Ludovic Courtès wrote: > but (i) "static inline" is safe, Yes sure. > (ii) who knows what silly > patches Apple will apply to their next GCC series, and (iii) let's not > put too much effort into systems that deliberately break things. I don't think this is fair towards Apple. The GCC developers

glob: fix includes

glob.c uses 'true' and 'false' without including . This breaks the compilation on IRIX: "glob.c", line 1391: error(1020): identifier "true" is undefined if ((flags & GLOB_ONLYDIR) && !DIRENT_MIGHT_BE_DIR (d)) ^ I'm fixing it like this: 2

strsignal: fix compilation error

On IRIX 6.5, the strsignal replacement fails to compile: "strsignal.c", line 69: error(1143): declaration is incompatible with "char *_sys_siglist[]" (declared at line 176 of "///usr/include/signal.h") static const char *_sys_siglist[NSIG]; ^ "strsignal.

getaddrinfo test: link error

On IRIX, the test-getaddrinfo program does not link, because it requires libintl (from gai_strerror.c). This should fix it. 2008-04-11 Bruno Haible <[EMAIL PROTECTED]> * modules/getaddrinfo-tests (Makefile.am): Define test_getaddrinfo_LDADD. *** modules/getaddrinfo-tests.orig

strsignal test: link error

Likewise for strsignal's test: 2008-04-11 Bruno Haible <[EMAIL PROTECTED]> * modules/strsignal-tests (Makefile.am): Define test_strsignal_LDADD. *** modules/strsignal-tests.orig2008-04-12 02:02:02.0 +0200 --- modules/strsignal-tests 2008-04-12 02:00:13.0 +02

getaddrinfo test: ignore failure on IRIX

On IRIX 6.5, the test-getaddrinfo fails like this: Finding www.ibm.com service https... res -2: Name or service not known FAIL: test-getaddrinfo Since there is already code to ignore a failure on Solaris, the same failure on IRIX (with a more POSIX compliant error code!) should be ignored as well

Re: inline related build failures on MacOS X 10.5

Peter O'Gorman wrote: > It is unlikely that there will be a version of gcc from Apple based on > gcc-4.3 or later (because Apple is currently not introducing any GPLv3 > software). Currently... They will have to buy into gcc 4.3 or newer in the long run. > Note that what will become Xcode-3.1 see

Re: stdarg: don't put compiler in gnu99 mode by default

Hi gmp maintainers, The #ifdefs for determining which variant of 'inline' or 'extern inline' don't work any more with the Apple GCC compiler on MacOS X. See the threads that started in http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00103.html http://lists.gnu.org/archive/html/bug-gnu