Re: perror bug

2011-03-14 Thread Bruno Haible
Eric Blake wrote on 2011-02-10: POSIX requires that this program have an identical first and last line: #include stdio.h #include string.h #include errno.h int main (void) { char *err = strerror(1000); printf (%s\n, err); errno = 2000; perror (hi); printf (%s\n, err);

Re: [PATCH 3/4] Add a CLOEXEC recvfd

2011-03-14 Thread Bastien ROUCARIES
On Sun, Mar 13, 2011 at 5:16 PM, Bruno Haible br...@clisp.org wrote: Hi Bastien, In order to avoid a race add a recvfd(int fd, int flags). flags could be O_CLOEXEC. ---  lib/passfd.c   |   58 +++-  lib/passfd.h   |    1 +  m4/afunix.m4

Re: [PATCH 3/4] Add a CLOEXEC recvfd

2011-03-14 Thread Bruno Haible
Bastien ROUCARIES wrote: recvfd exist under plan9 and I will prefer to use it in order to be compatible In order to be compatible, we would also need to have header files called u.h and libc.h [1], which we don't have. Plan9 compatibility has never been a goal for gnulib, and Plan9 is not

sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Keith Godfrey
Greetings, I recently compiled octave on RedHat Enterprise 5.4 and it produced a segfault on startup. Investigation as to why suggests that there is an incompatibility between gnulib and the system headers. Specifically, sigset_t in /usr/include is a struct containing an array. However gnulib's

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 12:38 AM, Bruno Haible br...@clisp.org wrote: Here's the result of testing passfd: Linux      OK      BSD4.4 way, MSG_CMSG_CLOEXEC FreeBSD    OK      BSD4.4 way OpenBSD    OK      BSD4.4 way NetBSD     FAIL    BSD4.4 way AIX        OK      BSD4.4 way HP-UX      OK  

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
Could you apply the attached patch It is a little bit more paranoid, and could be good on strange platform Bastien diff Description: Binary data

Re: passfd on more platforms

2011-03-14 Thread Eric Blake
On 03/13/2011 05:38 PM, Bruno Haible wrote: On mingw, I haven't even tried the module. It first requires - a 'socketpair' module for the test, - to rewrite the test to use the 'execute' module instead of fork(). Why do we even need a child process? Can't we test passing of an fd between

I'm happy to write patches

2011-03-14 Thread Reuben Thomas
Someone kindly pointed out privately that some of my suggestions would have a better chance of being implemented if I provided patches. I am only backward in doing so because a) I'm often wrong, b) even some of my better ideas are rightly rejected for other reasons; and c) many of my suggestions

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 12:38 AM, Bruno Haible wrote: On mingw, I haven't even tried the module. It first requires - a 'socketpair' module for the test, - to rewrite the test to use the 'execute' module instead of fork(). MinGW would need a total rewrite. The Win32 API requires you to duplicate

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 2:20 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 12:38 AM, Bruno Haible wrote: On mingw, I haven't even tried the module. It first requires   - a 'socketpair' module for the test,   - to rewrite the test to use the 'execute' module instead of fork(). MinGW

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 02:36 PM, Bastien ROUCARIES wrote: Or you could ask throught the socket, the process id of the receiving process than send the handle. Remember: It is assumed that the two sides have coordinated and agreed to transfer a file descriptor already, so that the sendfd is met with a

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 2:45 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 02:36 PM, Bastien ROUCARIES wrote: Or you could ask throught the socket, the process id of the receiving process than send the handle. Remember: It is assumed that the two sides have coordinated and agreed

Re: test-ignore-value.c warnings

2011-03-14 Thread Eric Blake
On 03/13/2011 01:57 PM, Bruno Haible wrote: Hi Eric, On OpenBSD 4.4, which uses a gcc version 3.3.5, I get these warnings: test-ignore-value.c:35: warning: `__warn_unused_result__' attribute directive ignored test-ignore-value.c:36: warning: `__warn_unused_result__' attribute directive

Re: Exception to space-tab rule

2011-03-14 Thread Jim Meyering
Reuben Thomas wrote: make syntax-check is complaining about space-tabs (sc_space_tab) in a sort of file where this is perfectly permissable: a .diff file. Why do I have a diff file in version control? Because I'm patching gnulib. Of course, I can add this to VC_LIST_ALWAYS_EXCLUDE_REGEX, but

Re: Exception to space-tab rule

2011-03-14 Thread Reuben Thomas
On 14 March 2011 14:23, Jim Meyering j...@meyering.net wrote: -    exit (1); -  exit (0); +    return 1; +  return 1; Was that intentional? i.e. should second return be return 0? -- http://rrt.sc3d.org

Re: Exception to space-tab rule

2011-03-14 Thread Jim Meyering
Reuben Thomas wrote: On 14 March 2011 14:23, Jim Meyering j...@meyering.net wrote: -    exit (1); -  exit (0); +    return 1; +  return 1; Was that intentional? i.e. should second return be return 0? Not at all. Thank you! I've fixed it locally.

Re: Exception to space-tab rule

2011-03-14 Thread Eric Blake
On 03/14/2011 08:23 AM, Jim Meyering wrote: However, I find that adding a whole new .x-sc_* file just to exempt an exceptional source file from one of the many syntax checks is a disproportionate burden. It has always bothered me to do that. So finally, here's a proposed maint.mk patch to

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 03:02 PM, Bastien ROUCARIES wrote: recv(socket, buf, 512) = return 17, buf = getfd\n0x12345678\0 parse getfd recvfd fails, or even worse it blocks (possibly forever) even if recvfd doesn't block, parsing 0x12345678\0 fails Why ? It is like sending and

Re: passfd on more platforms

2011-03-14 Thread Eric Blake
On 03/14/2011 08:39 AM, Paolo Bonzini wrote: On 03/14/2011 03:02 PM, Bastien ROUCARIES wrote: recv(socket, buf, 512) = return 17, buf = getfd\n0x12345678\0 parse getfd recvfd fails, or even worse it blocks (possibly forever) even if recvfd doesn't block, parsing

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 3:44 PM, Eric Blake ebl...@redhat.com wrote: On 03/14/2011 08:39 AM, Paolo Bonzini wrote: On 03/14/2011 03:02 PM, Bastien ROUCARIES wrote:      recv(socket, buf, 512) =  return 17, buf = getfd\n0x12345678\0      parse getfd      recvfd fails, or even worse it

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 03:44 PM, Eric Blake wrote: No, that's exactly the_wrong_ reason for TCP_NODELAY. You simply cannot expect message boundaries to be respected when using SOCK_STREAM. So, either sendfd/recvfd must be documented to work only on SOCK_DGRAM sockets, or they have to be

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 4:05 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 03:44 PM, Eric Blake wrote:  No, that's exactly the_wrong_  reason for TCP_NODELAY.  You simply  cannot expect message boundaries to be respected when using SOCK_STREAM.  So, either sendfd/recvfd must

VC-tag again

2011-03-14 Thread Reuben Thomas
This line in maint.mk: VC-tag = git tag -s -m '$(VERSION)' -u '$(gpg_key_ID)' does appear to be unused, because its syntax is wrong: there's no message (argument to -m), or equivalently, no tag name is specified. Is something like: VC-tag = git tag -s -m 'Sign version $(VERSION)' '$(VERSION)'

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 04:19 PM, Bastien ROUCARIES wrote: But that was a different problem. That was not related to sendfd/recvfd. However, there are cases in which you want to send a file descriptor as out-of-band messages on a stream socket, and libvirt also has one of those. Does sending as

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 4:36 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 04:19 PM, Bastien ROUCARIES wrote:  But that was a different problem.  That was not related to sendfd/recvfd.  However, there are cases in which you want to send a file descriptor as  out-of-band

Re: VC-tag again

2011-03-14 Thread Eric Blake
On 03/14/2011 09:35 AM, Reuben Thomas wrote: This line in maint.mk: VC-tag = git tag -s -m '$(VERSION)' -u '$(gpg_key_ID)' does appear to be unused, because its syntax is wrong: there's no message (argument to -m), or equivalently, no tag name is specified. Actually, the message _is_

Re: VC-tag again

2011-03-14 Thread Jim Meyering
Reuben Thomas wrote: This line in maint.mk: VC-tag = git tag -s -m '$(VERSION)' -u '$(gpg_key_ID)' does appear to be unused, because its syntax is wrong: there's no message (argument to -m), or equivalently, no tag name is specified. Is something like: VC-tag = git tag -s -m 'Sign

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 04:43 PM, Bastien ROUCARIES wrote: While using TCP out-of-band data would be an interesting solution for Windows, UDP doesn't have out-of-band data. So, if sendfd/recvfd is going to be limited to SOCK_DGRAM, using out-of-band data for Windows is not going to work. Could

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 4:50 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 04:43 PM, Bastien ROUCARIES wrote:  While using TCP out-of-band data would be an interesting solution for  Windows, UDP doesn't have out-of-band data.  So, if sendfd/recvfd is going  to be limited to

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote: Not sure BTW it will be really simple: - send as oob data if fail with WSAEOPNOTSUPP come back to normal send But it will _always_ fail if people are using sendfd/recvfd as

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote: Not sure BTW it will be really simple: - send as oob data if fail with WSAEOPNOTSUPP come back to normal send But it will _always_ fail if people are using sendfd/recvfd as we (should) document it, i.e. on SOCK_DGRAM sockets! And BTW I will

Re: sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Paul Eggert
On 03/14/2011 12:15 AM, Keith Godfrey wrote: https://savannah.gnu.org/bugs/?30685 Apparently octave's configure script is incorrectly deciding that sigset_t does not work, and is therefore incorrectly setting HAVE_SIGSET_T to 0. Can you please investigate config.log and see why that is so?

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote: Not sure BTW it will be really simple: - send as oob data if fail with WSAEOPNOTSUPP come

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini bonz...@gnu.org wrote: On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 05:03 PM, Bastien ROUCARIES wrote: Not sure BTW it

Re: passfd on more platforms

2011-03-14 Thread Eric Blake
On 03/14/2011 11:37 AM, Bastien ROUCARIES wrote: On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini bonz...@gnu.org wrote: On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Mon, Mar 14, 2011 at 5:05 PM, Paolo Bonzini bonz...@gnu.org wrote: On 03/14/2011 05:03

Re: passfd on more platforms

2011-03-14 Thread Bastien ROUCARIES
On Mon, Mar 14, 2011 at 6:39 PM, Eric Blake ebl...@redhat.com wrote: On 03/14/2011 11:37 AM, Bastien ROUCARIES wrote: On Mon, Mar 14, 2011 at 6:29 PM, Paolo Bonzini bonz...@gnu.org wrote: On Mon, Mar 14, 2011 at 17:10, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Mon, Mar 14, 2011

Re: passfd on more platforms

2011-03-14 Thread Paolo Bonzini
On Mon, Mar 14, 2011 at 18:40, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: It is easy to have a workable send/recvfd with SOCK_STREAM under unix (except the close problem) How so? You said that OOB is not supported by AF_UNIX stream sockets (only TCP, which does not support SCM_RIGHTS

Re: sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Paul Eggert
On 03/14/2011 09:29 AM, Keith Godfrey wrote: Have sigset is set to 1. In that case, please investigate why libgnu/signal.h is behaving as if HAVE_SIGSET_T is 0. Try doing diff -u libgnu/signal.in.h libgnu/signal.h and looking for HAVE_SIGSET_T. And try removing libgnu/signal.h and then typing

Re: VC-tag again

2011-03-14 Thread Reuben Thomas
On 14 March 2011 15:45, Jim Meyering j...@meyering.net wrote:  http://git.sv.gnu.org/cgit/coreutils.git/tree/README-release This is just the sort of document it would be useful to have in gnulib, though obviously the more of it that can be translated into rules in maint.mk the better. Before I

Re: warnings and -Werror

2011-03-14 Thread Simon Josefsson
Reuben Thomas r...@sc3d.org writes: The documentation for the warnings module says: It allows to use ‘-Werror’ at ‘make distcheck’ time but gives no clue as to how this is done; nor is -Werror mentioned in warnings.m4. Could we have a hint, please? (The documentation shows how to make the

Re: sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Godfrey, Keith
Hi Paul, Output of the commands are attached, as is sigprocmask.c, in case it might be of assistance. HAVE_SIGSET_T is converted to '1', and make treats it as '1' as well. Best, Keith On 03/14/2011 12:25 PM, Paul Eggert wrote: On 03/14/2011 09:29 AM, Keith Godfrey wrote: Have sigset

Re: warnings and -Werror

2011-03-14 Thread Reuben Thomas
On 14 March 2011 20:17, Simon Josefsson si...@josefsson.org wrote: Do you think this is useful?  Maybe warnings.m4 should unconditionally check for -Werror since it actually is a standard gcc parameter.  Then all projects doesn't have to hard code that test themselves. Alternatively, we

Making releases

2011-03-14 Thread Reuben Thomas
I finally cajoled maint.mk into actually making a stable release of GNU Zile. There are a couple of odd things about the final stages: 1. It doesn't upload the release tarball c. itself, it emits commands to do so. Why? 2. There's no post-release hook which I can use for my Freshmeat

Re: sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Paul Eggert
On 03/14/2011 05:46 AM, Godfrey, Keith wrote: HAVE_SIGSET_T is converted to '1', and make treats it as '1' as well. Thanks. Perhaps Bruno Haible can comment: he knows more about this issue. It appears to be a problem with older versions of GCC (4.1.2, say) when compiling C++, which I'm not

Re: passfd on more platforms

2011-03-14 Thread Bruno Haible
Bastien ROUCARIES wrote: according to postfix source NETBSD seems really strange... Do you know how to test ? /* * The CMSG_LEN send/receive workaround was originally developed for * OpenBSD 3.6 on SPARC64. After the workaround was verified to not break * Solaris 8 on SPARC64,

Re: passfd on more platforms

2011-03-14 Thread Bruno Haible
Bastien ROUCARIES wrote: Could you apply the attached patch It is a little bit more paranoid, and could be good on strange platfor Please, if you want me to apply a patch from now on, provide it with all details correct (in particular GNU style code) and a ChangeLog entry. In this patch,

Re: passfd on more platforms

2011-03-14 Thread Bruno Haible
Eric Blake asked: - to rewrite the test to use the 'execute' module instead of fork(). Why do we even need a child process? Can't we test passing of an fd between two threads of the same process? 1) Because the typical use-case is passing file descriptors between different processes.

Re: sigprocmask.c appears to be incompatible w/ system headers

2011-03-14 Thread Bruno Haible
Godfrey, Keith wrote: Output of the commands are attached In make.txt you have this command: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -pthread -no-undefined -lm -lm -lm -lm -lm -L/global/home/keith/lib -o libgnu.la c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo close-hook.lo