[PATCH] tests: readlink* ("", ... fails with EINVAL on newer kernels

coreutils' "make check" failed on rawhide due to a kernel change in how readlink and readlinkat treat the empty file name. Before, they'd fail with ENOENT. Now, it's EINVAL. This fixes the tests to accommodate the new errno value: >From dc44690985e727ac2ef5af783a495a369223ab69 Mon Sep 17 00:00:00

Re: uninorm/nfc - Unicode version?

Simon Josefsson wrote on 2011-01-19: > OTOH, by only relicensing some modules, I don't think I can use an > installed libunistring shared library, which would contain LGPLv3+ code > too. Yes, I agree, this would be too hairy from a legal point of view. You can explain to a lawyer which .so file re

Re: uninorm/nfc - Unicode version?

Hi Simon, I promised in : > > ... therefore, yes, I'm willing to relicense the parts of libunistring that > > libidna needs under LGPLv2+. Please come back to me again when you have the > > complete and minimal list of the module

Re: uninorm/nfc - Unicode version?

Bruno Haible writes: >> A daemon approach with a smaller wrapper library to communicate with it >> would avoid this concern too > > I'm not in favour of implementing bloated or technically bad solutions for > the reasons of copyright... > >> -- would you be willing to relicense libunistring (or p

Re: lib-symbol-visibility

Hi Simon, > +Notice: > +The value of $(CFLAG_VISIBILITY) needs to be added to the CFLAGS for the > +compilation of all sources that make up the library. Yes, this makes sense. I pushed it in your name. Bruno -- In memoriam Rachel Levy

Re: non-blocking I/O

On Tue, Mar 29, 2011 at 6:43 PM, Bastien ROUCARIES wrote: > On Tue, Mar 29, 2011 at 6:34 PM, Bastien ROUCARIES > wrote: >> On Tue, Mar 29, 2011 at 5:16 PM, Bruno Haible wrote: >>> Paolo Bonzini wrote: Without guessing what your bias is, I also :) prefer to implement {g,s}et_nonblock_fl

Re: non-blocking I/O

On Tue, Mar 29, 2011 at 6:34 PM, Bastien ROUCARIES wrote: > On Tue, Mar 29, 2011 at 5:16 PM, Bruno Haible wrote: >> Paolo Bonzini wrote: >>> Without guessing what your bias is, I also :) prefer to implement >>> {g,s}et_nonblock_flag functions.  It would use either >>> SetNamedPipeHandleState or i

Re: proposed new module breadlinkat

On 03/29/2011 04:29 AM, Bruno Haible wrote: > That looks like a lot of complexity that is useful only to Emacs and > not to other packages. I should have explained that I had another agenda here: improving the performance of programs like coreutils, which invoke areadlink on a non-huge link, do a

Re: non-blocking I/O

On Tue, Mar 29, 2011 at 5:16 PM, Bruno Haible wrote: > Paolo Bonzini wrote: >> Without guessing what your bias is, I also :) prefer to implement >> {g,s}et_nonblock_flag functions.  It would use either >> SetNamedPipeHandleState or ioctlsocket (using the socket detection trick >> in sockets.c to d

Re: non-blocking I/O

Paolo Bonzini wrote: > Without guessing what your bias is, I also :) prefer to implement > {g,s}et_nonblock_flag functions. It would use either > SetNamedPipeHandleState or ioctlsocket (using the socket detection trick > in sockets.c to detect sockets, and then GetFileType to detect pipes if >

Re: non-blocking I/O on Woe32

Eric Blake wrote: > Mingw has named pipes, but they appear to > reside in a different namespace than the normal file system, and the > gnulib mkfifo() implementation current always fails with ENOSYS on > mingw. Unless we find a way to expose named pipes in the normal file > system on mingw, then y

Re: non-blocking I/O

On 03/29/2011 06:45 AM, Eric Blake wrote: > Mingw supports named pipes (witness the mkfifo gnulib function), Oops, hit send too soon. Mingw has named pipes, but they appear to reside in a different namespace than the normal file system, and the gnulib mkfifo() implementation current always fails

Re: Documentation buglet

Bruno Haible writes: > Bastien ROUCARIES wrote: >> > getaddrinfo documentation >> > Portability problems not fixed by Gnulib: >> > On Windows, this function is declared in rather than >> > in . >> > >> > but it is fixed by netdb module. > > Actually, since the declaration in lib/netdb.in.h is

Re: non-blocking I/O

On Tue, Mar 29, 2011 at 2:08 PM, Bruno Haible wrote: > Hi Paolo, Eric, > >> prefer to implement {g,s}et_nonblock_flag functions. ... >> This module can then be used to build a fcntl F_GETFL/F_SETFL >> implementation, but it is not very important to do so. > > Nevertheless in gnulib we try to offer

Re: Documentation buglet

Bastien ROUCARIES wrote: > > getaddrinfo documentation > > Portability problems not fixed by Gnulib: > > On Windows, this function is declared in rather than in > > . > > > > but it is fixed by netdb module. Actually, since the declaration in lib/netdb.in.h is inside a #if @GNULIB_GETADDRINF

Re: non-blocking I/O

On 03/29/2011 06:08 AM, Bruno Haible wrote: > According to the include files the support is the following: > > - glibc, MacOS X, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX, IRIX, OSF/1, > Solaris, > Cygwin, Interix have all three APIs, > - mingw lacks F_GETFL, O_NONBLOCK, O_NDELAY

Re: non-blocking I/O

Hi Paolo, Eric, > prefer to implement {g,s}et_nonblock_flag functions. ... > This module can then be used to build a fcntl F_GETFL/F_SETFL > implementation, but it is not very important to do so. Nevertheless in gnulib we try to offer the POSIX APIs, if possible. There are three APIs for non-bl

Re: proposed new module breadlinkat

Hi Paul, > In seeking to have GNU Emacs use gnulib's areadlink module I > ran into a problem. Emacs has its own xmalloc and xfree > functions that block interrupts, and it can't simply use > areadlink since areadlink uses malloc without blocking > interrupts. One workaround would be to block int

Re: [libvirt] mingw: virsh event loop failure in current git

On Tue, Mar 29, 2011 at 8:48 AM, Paolo Bonzini wrote: > On 03/29/2011 01:27 AM, Eric Blake wrote: >> >> Paolo, any thoughts on the best approach to take?  (I know which way I'm >> leaning, but want some feedback before I give away my bias). > > Without guessing what your bias is, I also :) prefer