Re: remove 'exit'?

On Sun, May 1, 2011 at 8:47 PM, Simon Josefsson wrote: > How about just removing the module?  If something breaks, the maintainer > can track it down, and will notice that the module disappeared, and fix > the package.  If nothing breaks, it is normally just a portability > problem that will be no

[PATCH] getopt: for ambiguous options, enumerate the possibilities.

* lib/getopt.c (_getopt_internal_r): Merge glibc change printing the ambiguous options when an ambiguous prefix is given. This was http://sourceware.org/bugzilla/show_bug.cgi?id=7101. The merged glibc change was http://sourceware.org/git/?p=glibc.git;a=commit;h=bd25564e1e98910ed69043ed6a6f884ce60e

Re: glob-libc.h not installed

On 05/25/11 14:44, Reuben Thomas wrote: On 9 May 2011 17:19, Bruce Korb wrote: On 05/08/11 15:24, Reuben Thomas wrote: Still missing a header: ... In file included from lposix.c:25:0: /usr/local/include/libposix/glob.h:381:23: fatal error: glob-libc.h: No such file or directory The deri

Re: bug#8732: uinttostr: comparison of unsigned expression < 0 is always false

On 05/25/11 14:48, Eric Blake wrote: > This patch silences the gcc warning even for gcc too old to honor the > pragma, but I can't help but feel that it might be too gross (it makes > functions like uinttostr larger in size). > ... > - *--p = '-'; > + if (ii) > +*--p = '-'; Yes,

Re: bug#8732: uinttostr: comparison of unsigned expression < 0 is always false

[adding bug-gnulib] On 05/25/2011 03:29 PM, Eric Blake wrote: >>> building coreutils-8.12 with '--enable-gcc-warnings' fails on my SLES 10.3 >>> server: >>> >>> CC uinttostr.o >>> cc1: warnings being treated as errors >>> In file included from uinttostr.c:3: >>> anytostr.c: In function 'u

Re: glob-libc.h not installed

On 9 May 2011 17:19, Bruce Korb wrote: > On 05/08/11 15:24, Reuben Thomas wrote: >> >> Still missing a header: > > ... >> >> In file included from lposix.c:25:0: >> /usr/local/include/libposix/glob.h:381:23: fatal error: glob-libc.h: >> No such file or directory > > The derived file "glob.h" uncon

mingw: test-poll pipe part fails

Output from a test run on mingw Unconnected socket test... passed Connected sockets test... passed General socket test with fork... passed Pipe test... failed (expecting POLLHUP after shutdown) FAIL: test-poll.exe This affects the attempt to make libvirtd working on Windows. libvirtd relies on po

[PATCH] getcwd: work around mingw bug

mingw getcwd(buf, 0) fails with ERANGE, instead of the required EINVAL. Since we're already replacing getcwd on mingw, the workaround is trivial. * lib/getcwd-lgpl.c (rpl_getcwd): Guarantee correct error. Reported by Matthias Bolte. Signed-off-by: Eric Blake --- It took me much less time to wr

mingw: test-getcwd-lgpl assertion failure

ASSERT (errno == EINVAL) in line 98 fails, errno is set to ERANGE instead of EINVAL. Found via libvirt on mingw with recent gnulib version: f4c4af09bcf3f0497dc3347ecc0a0b3c9ee1ff63 Matthias

Re: patch on x86-interix

[CCing bug-gnulib] Markus Duft wrote in : > For quite a while now, i have patch working on x86-interix with a small patch > ( :D ). I'd really love to see this patch ([1]) go upstream, if that's ok > with you. Could you please ta

Re: mingw: test-ftell and test-ftello assertion failures

On 05/25/2011 02:37 PM, Matthias Bolte wrote: > In both tests ASSERT (ftell (stdin) == -1); in line 45 fails. ftell > (stdin) returns 0 in this case. > > Found via libvirt on mingw with recent gnulib version: > f4c4af09bcf3f0497dc3347ecc0a0b3c9ee1ff63 In this particular case, test-ftell.sh is cal

mingw: test-ftell and test-ftello assertion failures

In both tests ASSERT (ftell (stdin) == -1); in line 45 fails. ftell (stdin) returns 0 in this case. Found via libvirt on mingw with recent gnulib version: f4c4af09bcf3f0497dc3347ecc0a0b3c9ee1ff63 Matthias

coping with conflicting strerror_r signatures [was: strerror vs. threads]

On 05/25/2011 08:32 AM, Eric Blake wrote: > If glibc were to change GNU strerror_r to _always_ populate buf, in > addition to the return string, then you could blindly call either > variant of strerror_r and just ignore the return value; the only > remaining problem is making sure you provide a lar

Re: test-intprops.c: many new warnings

On 05/24/11 17:06, Eric Blake wrote: > Would it be possible instead to write forwarding macros? Sorry, I don't see how. The macros might expand to runtime tests. > Otherwise, we are just disabling the warnings for this test, but the > warnings will still byte us in regular code. -Wtype-limits i

Re: [PATCH] strerror_r: avoid compiler warning

Hi Eric, > On 05/21/2011 12:02 PM, Bruno Haible wrote: > > Eric Blake wrote: > >> @@ -48,7 +48,6 @@ AC_DEFUN([gl_FUNC_STRERROR_R], > >> [AC_LANG_PROGRAM( > >> [[#include > >>#include > >> - int strerror_r (int, char *, size_t);

Re: [PATCH] strerror_r: avoid compiler warning

On 05/25/2011 03:49 AM, Bruno Haible wrote: >> in the latter case, deleting the >> only declaration here makes compilation fail (which is what we want, >> since that means the system didn't really comply with POSIX after all). > > The usual gnulib approach is to provide the declaration only. This

Re: strerror vs. threads

On 05/25/2011 02:59 AM, Simon Josefsson wrote: >> Therefore, I'm afraid that the more portable choice is to consistently >> stick to the standard definition, rather than the GNU definition, even >> if the GNU definition is slightly easier to use. > > Yes. What we'd really like is a dependency sch

Re: strerror vs. threads

Eric Blake writes: > On 05/24/2011 03:30 PM, Simon Josefsson wrote: >> Maybe there could be a strerror_r-gnu and strerror_r-posix choice? Or a >> strerror_r-posixlean to just do the minimum required by POSIX. > > I think a strerror_r-gnu module might be nice, especially now that I've > posted a