Re: perror bug
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);
return 0;
}
but on cygwin 1.7.7, the perror() corrupts the buffer returned by
strerror(). We should probably fix that in gnulib as part of our perror
module.
Yes, but first let's see which other problems there are.
The program below tests whether strerror's buffer is read-write (i.e.
whether it is overwritten by subsequent strerror calls) and, when compiled
with -DPERROR, whether perror calls clobber the strerror buffer.
The result is:
read-write buffer?perror reuses strerror buffer?
glibc yes no
OpenBSD yes no
OSF/1 yes no
Cygwin 1.5 yes yes
Cygwin 1.7 yes yes
mingw yes no
That's the situation without gnulib. With gnulib, there are three problems
in toto:
1) The strerror_r replacement, when EXTEND_STRERROR_R is defined,
clobbers the strerror function's buffer, which it shouldn't.
2) The perror replacement uses strerror, thus clobbering the strerror
buffer.
3) On Cygwin, perror clobbers the strerror buffer.
The fix for 1) should be to move most of lib/strerror.c to lib/strerror_r.c.
The fix for 2) should be to change lib/perror.c to call strerror_r.
The fix for 3) should be to change m4/perror.m4 to enable the replacement
on Cygwin.
I think the three fixes should be applied in this order, bottom-up.
Bruno
foo.c
#include errno.h
#include stdio.h
#include string.h
int main ()
{
const char *msg1;
const char *msg2;
const char *msg3;
msg1 = strerror (ENOENT);
printf (msg1 before: %s\n, msg1);
msg2 = strerror (-4);
printf (msg2 before: %s\n, msg2);
msg3 = strerror (1729576);
printf (msg3 before: %s\n, msg3);
freopen (/dev/null, w, stderr);
#ifdef PERROR
errno = EACCES; perror ();
errno = -5; perror ();
errno = 153272; perror ();
#else
strerror (EACCES);
strerror (-5);
strerror (153272);
#endif
printf (msg1 after: %s\n, msg1);
printf (msg2 after: %s\n, msg2);
printf (msg3 after: %s\n, msg3);
return 0;
}
===
Re: [PATCH 3/4] Add a CLOEXEC recvfd
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 | 22 +
modules/passfd | 1 +
This is pretty good as well. But there's no need for two functions recvfd and
recvfd2. Better merge them into a single function. It's easy for the callers
to pass a 0 flags argument. In the POSIX API, a separate function was
introduced only when the previous function already existed for a long time,
like pipe()/pipe2() and accept()/accept4().
recvfd exist under plan9 and I will prefer to use it in order to be
compatible
Bastien
Also, it is better to test 'flags O_CLOEXEC' instead of 'flags == O_CLOEXEC'
because
- The flags argument is conceptually a bit mask.
- O_CLOEXEC is 0 on some platforms (that don't support this flag), and
passing a 0 flags argument ought to _not_ set the close-on-exec flag.
Other than this, I applied the usual untabification and .m4 file indentation.
A possible simplification would be to assume that MSG_CMSG_CLOEXEC is a macro
when it exists, and thus simplify #if HAVE_MSG_CMSG_CLOEXEC to
#if defined MSG_CMSG_CLOEXEC.
2011-03-13 Bastien Roucariès roucaries.bast...@gmail.com
Bruno Haible br...@clisp.org
passfd module, part 3.
* lib/passfd.h (recvfd): Add a flags argument.
* lib/passfd.c: Include fcntl.h, cloexec.h.
(recvfd): Add a flags argument.
* m4/afunix.m4 (gl_SOCKET_AFUNIX): Test whether MSG_CMSG_CLOEXEC
exists.
* modules/passfd (Depends-on): Add cloexec.
Suggested by Eric Blake.
--- lib/passfd.c.orig Sun Mar 13 16:26:20 2011
+++ lib/passfd.c Sun Mar 13 15:53:28 2011
@@ -19,6 +19,7 @@
#include passfd.h
#include errno.h
+#include fcntl.h
#include stddef.h
#include stdlib.h
#include string.h
@@ -35,6 +36,8 @@
# include winsock2.h
#endif
+#include cloexec.h
+
/* sendfd sends the file descriptor fd along the socket
to a process calling recvfd on the other end.
@@ -84,11 +87,12 @@
}
/* recvfd receives a file descriptor through the socket.
+ The flags are a bitmask, possibly including O_CLOEXEC (defined in
fcntl.h).
Return 0 on success, or -1 with errno set in case of error.
*/
int
-recvfd (int sock)
+recvfd (int sock, int flags)
{
char recv = 0;
const int mone = -1;
@@ -96,6 +100,12 @@
struct iovec iov[1];
struct msghdr msg;
+ if ((flags ~O_CLOEXEC) != 0)
+ {
+ errno = EINVAL;
+ return -1;
+ }
+
/* send at least one char */
iov[0].iov_base = recv;
iov[0].iov_len = 1;
@@ -108,6 +118,11 @@
#if HAVE_UNIXSOCKET_SCM_RIGHTS_BSD44_WAY
struct cmsghdr *cmsg;
char buf[CMSG_SPACE (sizeof (fd))];
+# if HAVE_MSG_CMSG_CLOEXEC
+ int flags_recvmsg = (flags O_CLOEXEC ? MSG_CMSG_CLOEXEC : 0);
+# else
+ int flags_recvmsg = 0;
+# endif
msg.msg_control = buf;
msg.msg_controllen = sizeof (buf);
@@ -119,7 +134,7 @@
memcpy (CMSG_DATA (cmsg), mone, sizeof (mone));
msg.msg_controllen = cmsg-cmsg_len;
- if (recvmsg (sock, msg, 0) 0)
+ if (recvmsg (sock, msg, flags_recvmsg) 0)
return -1;
cmsg = CMSG_FIRSTHDR (msg);
@@ -133,13 +148,43 @@
}
memcpy (fd, CMSG_DATA (cmsg), sizeof (fd));
+
+# if !HAVE_MSG_CMSG_CLOEXEC
+ /* set close-on-exec flag */
+ if (flags O_CLOEXEC)
+ {
+ if (set_cloexec_flag (fd, true) 0)
+ {
+ int saved_errno = errno;
+ (void) close (fd);
+ errno = saved_errno;
+ return -1;
+ }
+ }
+# endif
+
return fd;
+
#elif HAVE_UNIXSOCKET_SCM_RIGHTS_BSD43_WAY
msg.msg_accrights = fd;
msg.msg_accrightslen = sizeof (fd);
if (recvmsg (sock, msg, 0) 0)
return -1;
+
+ /* set close-on-exec flag */
+ if (flags O_CLOEXEC)
+ {
+ if (set_cloexec_flag (fd, true) 0)
+ {
+ int saved_errno = errno;
+ (void) close (fd);
+ errno = saved_errno;
+ return -1;
+ }
+ }
+
return fd;
+
#else
errno = ENOSYS;
return -1;
--- lib/passfd.h.orig Sun Mar 13 16:26:20 2011
+++ lib/passfd.h Sun Mar 13 15:43:03 2011
@@ -23,7 +23,7 @@
#endif
extern int sendfd (int sock, int fd);
-extern int recvfd (int sock);
+extern int recvfd (int sock, int flags);
#ifdef __cplusplus
}
--- m4/afunix.m4.orig Sun Mar 13 16:26:20 2011
+++ m4/afunix.m4 Sun Mar 13 15:58:06 2011
@@ -1,4 +1,4 @@
-# afunix.m4 serial 2
+# afunix.m4 serial 3
dnl Copyright (C) 2011 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@
Re: [PATCH 3/4] Add a CLOEXEC recvfd
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 one of the portability targets for gnulib. If you really want recvfd(int) and recvfd2(int,int), then please submit a patch relative to the current gnulib contents, taking care of details - tabs, typos, unused variables, gcc -Wall warnings, etc. all being fixed. Bruno [1] http://swtch.com/plan9port/man/man3/sendfd.html
sigprocmask.c appears to be incompatible w/ system headers
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 sigprocmask.c looks to treat it as an integer, with the same prototype as defined in gnulib's signal.h. Octave crashes when calling the functions defined in sigprocmask.c (e.g., libgnu::sigemptyset() and libgnu::sigprocmask()), presumably because these functions are receiving a structure pointer instead of an int pointer. Commenting out the entirety of sigprocmask.c and recompiling (forcing calls to these functions to link w/ the system library) produces a stable octave build. I really don't understand these matters as this is my first interaction w/ both octave and gnulib, but the octave maintainer(s) suggest that this is a bug in gnulib. Their argument seems reasonable. octave bug: https://savannah.gnu.org/bugs/?30685 Thank you very much, and best regards, Keith
Re: passfd on more platforms
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 BSD4.3 way IRIX OK BSD4.3 way OSF/1 OK BSD4.4 way Solaris OK BSD4.3 way Cygwin FAIL BSD4.4 way It is a bit surprising that Solaris 10 says that it doesn't support the BSD4.4 way. That is because checking for UNIX domain sockets SCM_RIGHTS that behave in BSD4.4 way... no because CMSG_SPACE etc. are not declared by sys/socket.h by default. I'm not sure whether gnulib should define _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, or _POSIX_C_SOURCE. But's let's leave it as is for now, since the BSD4.3 way works. On NetBSD 5.0, the test reports sendfd: Invalid argument and then hangs. 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, it was hard-coded with Postfix 2.3 for all * platforms because of increasing pressure to work on other things. The * workaround does nothing for 32-bit systems. * * The investigation was reopened with Postfix 2.7 because the workaround * broke with NetBSD 5.0 on 64-bit architectures. This time it was found * that OpenBSD = 4.3 on AMD64 and SPARC64 needed the workaround for * sending only. The following platforms worked with and without the * workaround: OpenBSD 4.5 on AMD64 and SPARC64, FreeBSD 7.2 on AMD64, * Solaris 8 on SPARC64, and Linux 2.6-11 on x86_64. * * As this appears to have been an OpenBSD-specific problem, we revert to * the Postfix 2.2 behavior. Instead of hard-coding the workaround for * all platforms, we now detect sendmsg() errors at run time and turn on * the workaround dynamically. * * The workaround was made run-time configurable to investigate the problem * on multiple platforms. Though set_unix_pass_fd_fix() is over-kill for * this specific problem, it is left in place so that it can serve as an * example of how to add run-time configurable workarounds to Postfix. */ On Cygwin, the test fails: recvfd: Permission denied FAIL: test-passfd.exe cygwin does not implement this feature and will resort to use mingw emulation of part of, until fixed in core... On mingw, I haven't even tried the module. It first requires - a 'socketpair' module for the test, In all the case passing fd is done through socket - to rewrite the test to use the 'execute' module instead of fork(). Bastien
Re: passfd on more platforms
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
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 two threads of the same process? (However, I agree that since both passfd and recvfd are blocking, it does require multiple threads or multiple processes to test correctly). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
I'm happy to write patches
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 are so simple it'd take less time for a committer to implement them than to process a patch from me (although if it's time invested in educating me, then thanks, and I'll do my best to learn). So please do consider all my suggestions (or at least the trivial ones) as coming with an implicit I'm happy to write a patch for this, and meantime I'll try to remember to make it explicit. -- http://rrt.sc3d.org
Re: passfd on more platforms
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 the handle in the context of the sending process, and send the new handle somehow to the receiving process. For example you can get information on the socket using gethostname (getpeername on the other side), create a named pipe based on the name, and send the handle on the named pipe. It probably could fit within the sendfd/recvfd API, at least. Paolo
Re: passfd on more platforms
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 would need a total rewrite. The Win32 API requires you to duplicate the handle in the context of the sending process, and send the new handle somehow to the receiving process. For example you can get information on the socket using gethostname (getpeername on the other side), create a named pipe based on the name, and send the handle on the named pipe. 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 recvfd instead of an ordinary read. Bastien It probably could fit within the sendfd/recvfd API, at least. Paolo
Re: passfd on more platforms
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 recvfd instead of an ordinary read. No, you cannot unfortunately. Say that process 1 will do this: send getfd\n sendfd then the following will work on Unix in process 2: recv(socket, buf, 512) = return 6, buf = getfd\n parse getfd recvfd If the recvfd info is sent on the normal channel (i.e. not out-of-band), process 2 is going to fail like this: 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 Paolo
Re: passfd on more platforms
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 to transfer a file descriptor already, so that the sendfd is met with a recvfd instead of an ordinary read. No, you cannot unfortunately. Say that process 1 will do this: send getfd\n sendfd then the following will work on Unix in process 2: recv(socket, buf, 512) = return 6, buf = getfd\n parse getfd recvfd If the recvfd info is sent on the normal channel (i.e. not out-of-band), process 2 is going to fail like this: 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 receiving data throught a protocol. i will emulate AF_UNIX by tcp socket over localhost with TCP_NODELAY And we already send data using unix fd passing Bastien Paolo
Re: test-ignore-value.c warnings
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 ignored test-ignore-value.c:37: warning: `__warn_unused_result__' attribute directive ignored test-ignore-value.c:38: warning: `__warn_unused_result__' attribute directive ignored test-ignore-value.c:39: warning: `__warn_unused_result__' attribute directive ignored The reason is that __warn_unused_result__ was introduced in gcc 3.4, not in gcc 3.1, as the code appears to assume. OK to fix this? 2011-03-13 Bruno Haible br...@clisp.org ignore-value tests: Avoid warnings. * tests/test-ignore-value.c (_GL_ATTRIBUTE_RETURN_CHECK): Define to empty for gcc 3.4. Good to go - thanks for doing this. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Exception to space-tab rule
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 maybe
.diff files should be excluded from this check anyway?
They're expected only in .diff files for which
the original has context lines that start with a TAB.
For that reason (in gnulib, that is only a very small fraction
of all files), I think it's slightly better to let those who
need it add a line like this to a file named .x-sc_space_tab
^gl/lib/.*\.c\.diff$
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 implement a better way,
followed by the change induced in coreutils where I remove its 24
.x-sc_* files, replacing them with just 30 lines at the end of cfg.mk:
Notes on the naming of these new exception-specifying variables:
- the resulting variable names are rather long. I erred on the side
of being too descriptive. They're going to be used at most once, then
probably forgotten forever.
- I don't like the fact that they have a common *suffix* rather
than a common prefix. That's just what I did in the first cut.
They do have a common sc_ suffix, so maybe that's ok,
but the long common part, -exclude_file_name_regexp is at the end,
and that makes the list in cfg.mk harder to read, so I'm leaning
towards reversing, i.e., changing this
sc_space_tab-exclude_file_name_regexp = \
to this
_exclude_file_name_regexp--sc_space_tab = \
Note the leading underscore and two hyphens. The former to make
it less likely to collied with application names, and the latter
to make it clearer where the long common prefix ends and the
variable suffix starts.
Plus I'll have to split the long line 10 lines down:
diff --git a/top/maint.mk b/top/maint.mk
index 303e9c1..0720dc7 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -57,11 +57,12 @@ endif
# In order to be able to consistently filter .-relative names,
# (i.e., with no $(srcdir) prefix), this definition is careful to
# remove any $(srcdir) prefix, and to restore what it removes.
+_sc_excl = $(if
$($@-exclude_file_name_regexp),$($@-exclude_file_name_regexp),^$$)
VC_LIST_EXCEPT = \
$(VC_LIST) | sed 's|^$(_dot_escaped_srcdir)/||' \
| if test -f $(srcdir)/.x-$@; then grep -vEf $(srcdir)/.x-$@; \
else grep -Ev -e $${VC_LIST_EXCEPT_DEFAULT-ChangeLog}; fi \
- | grep -Ev -e '$(VC_LIST_ALWAYS_EXCLUDE_REGEX)' \
+ | grep -Ev -e '($(VC_LIST_ALWAYS_EXCLUDE_REGEX)|$(_sc_excl))' \
$(_prepend_srcdir_prefix)
ifeq ($(origin prev_version_file), undefined)
@@ -196,6 +197,12 @@ syntax-check: $(local-check)
# halt
#
# Message to display before to halting execution.
+#
+# Finally, you may exempt files based on an ERE matching file names.
+# For example, to exempt from the sc_space_tab check all files with the
+# .diff suffix from the set this Make variable:
+#
+# sc_space_tab-exclude_file_name_regexp = \.diff$
# By default, _sc_search_regexp does not ignore case.
export ignore_case =
@@ -233,7 +240,10 @@ define _sc_search_regexp
\
: Filter by file name; \
if test -n $$in_files; then \
- files=$$(find $(srcdir) | grep -E $$in_files); \
+ _gl_exclude_re='$($@-exclude_file_name_regexp)'; \
+ test -z $$_gl_exclude_re _gl_exclude_re='^$$'; \
+ files=$$(find $(srcdir) | grep -E $$in_files\
+ | grep -Ev $$_gl_exclude_re); \
else
\
files=$$($(VC_LIST_EXCEPT)); \
if test -n $$in_vc_files; then \
From 04cf87961db3aedf5966f3547ec19d532b131877 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 14 Mar 2011 14:26:38 +0100
Subject: [PATCH] maint: stop using .x-sc_* files to list syntax-check
exemptions
Instead, use the brand new mechanism with which you merely use a
variable (derived from the rule name) defined in cfg.mk to an ERE
matching the exempted file names.
* Makefile.am (syntax_check_exceptions): Remove variable.
(EXTRA_DIST): Remove use of the variable.
* cfg.mk (sc_x_sc_dist_check): Remove rule, no longer useful.
(sc_space_tab-exclude_file_name_regexp): Define variable.
(sc_bindtextdomain-exclude_file_name_regexp): Likewise.
(sc_unmarked_diagnostics-exclude_file_name_regexp): Likewise.
(sc_error_message_uppercase-exclude_file_name_regexp):
Re: Exception to space-tab rule
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
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
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 implement a better way, followed by the change induced in coreutils where I remove its 24 .x-sc_* files, replacing them with just 30 lines at the end of cfg.mk: I _love_ it! Let's get those naming issues resolved, since using cfg.mk for this instead of lots of new little files is very nice. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: passfd on more platforms
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 receiving data throught a protocol. i will emulate AF_UNIX by tcp socket over localhost with TCP_NODELAY 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 rethought (if possible at all). Paolo
Re: passfd on more platforms
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 0x12345678\0 fails Why ? It is like sending and receiving data throught a protocol. i will emulate AF_UNIX by tcp socket over localhost with TCP_NODELAY 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 rethought (if possible at all). Note that just last week libvirt found an issue with SOCK_STREAM hanging forever on recvfd when the sendfd side was skipped, but SOCK_DGRAM was able to reliably detect when the sending side of the socket is closed. I'm perfectly fine with documenting that sendfd/recvfd must be used on SOCK_DGRAM only. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: passfd on more platforms
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 blocks (possibly forever) even if recvfd doesn't block, parsing 0x12345678\0 fails Why ? It is like sending and receiving data throught a protocol. i will emulate AF_UNIX by tcp socket over localhost with TCP_NODELAY 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 rethought (if possible at all). Note that just last week libvirt found an issue with SOCK_STREAM hanging forever on recvfd when the sendfd side was skipped, but SOCK_DGRAM was able to reliably detect when the sending side of the socket is closed. I'm perfectly fine with documenting that sendfd/recvfd must be used on SOCK_DGRAM only. Will work for me Bastien
Re: passfd on more platforms
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 rethought (if possible at all). Note that just last week libvirt found an issue with SOCK_STREAM hanging forever on recvfd when the sendfd side was skipped, but SOCK_DGRAM was able to reliably detect when the sending side of the socket is closed. I'm perfectly fine with documenting that sendfd/recvfd must be used on SOCK_DGRAM only. 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. From a quick experiment, BTW, on a SOCK_DGRAM Unix socket you don't need to send fake data at the same time, but I may be wrong and/or that may not be portable. Paolo
Re: passfd on more platforms
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 be documented to work only on SOCK_DGRAM sockets, or they have to be rethought (if possible at all). Note that just last week libvirt found an issue with SOCK_STREAM hanging forever on recvfd when the sendfd side was skipped, but SOCK_DGRAM was able to reliably detect when the sending side of the socket is closed. I'm perfectly fine with documenting that sendfd/recvfd must be used on SOCK_DGRAM only. 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 oob data process id will fall on the previous trap on SOCK_STREAM ? oob are not implemented for unix so it will work under windows emulation Bastien From a quick experiment, BTW, on a SOCK_DGRAM Unix socket you don't need to send fake data at the same time, but I may be wrong and/or that may not be portable. Paolo
VC-tag again
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)' -u '$(gpg_key_ID)' intended? -- http://rrt.sc3d.org
Re: passfd on more platforms
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 oob data process id will fall on the previous trap on SOCK_STREAM ? I was using out-of-band as a generic term, so SCM_RIGHTS also falls under the definition of out-of-band. oob are not implemented for unix so it will work under windows emulation 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. On the other hand, if sendfd/recvfd is limited to SOCK_DGRAM, it is okay under Windows to send the handle normally as a UDP datagram through send/recv (your original plan). The limitation of sendfd/recvfd to SOCK_DGRAM is perfectly sane---I just wanted to point out that it would not be possible for libvirt to use sendfd, at least in one of the two scenarios where it is currently using SCM_RIGHTS. Paolo
Re: passfd on more platforms
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 messages on a stream socket, and libvirt also has one of those. Does sending as oob data process id will fall on the previous trap on SOCK_STREAM ? I was using out-of-band as a generic term, so SCM_RIGHTS also falls under the definition of out-of-band. oob are not implemented for unix so it will work under windows emulation 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 we know from fd if it is a udp or tcp socket ? - if tcp send as OOB - if udp send normally On the other hand, if sendfd/recvfd is limited to SOCK_DGRAM, it is okay under Windows to send the handle normally as a UDP datagram through send/recv (your original plan). The limitation of sendfd/recvfd to SOCK_DGRAM is perfectly sane---I just wanted to point out that it would not be possible for libvirt to use sendfd, at least in one of the two scenarios where it is currently using SCM_RIGHTS. Paolo Bastien
Re: VC-tag again
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_ $(VERSION). Rather, it looks like this is missing a tag name, which should be v$(VERSION) (that is, coreutils 8.10 was tagged as v8.10). Is something like: VC-tag = git tag -s -m 'Sign version $(VERSION)' '$(VERSION)' -u '$(gpg_key_ID)' intended? Lately, Jim uses the build-aux/do-release-commit-and-tag script for this instead of a maint.mk makefile rule, which is probably why it isn't very well tested. Maybe it's worth removing this as cruft and instead encouraging the use of do-release-commit-and-tag in more places? That script also drops the -u argument, on the grounds that you have probably configured 'git config user.signingkey ...' correctly in the first place. It basically uses: git tag -s -m '$(PACKAGE) $(VERSION)' v$(VERSION) -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: VC-tag again
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 version $(VERSION)' '$(VERSION)' -u '$(gpg_key_ID)' Hi Reuben, That definitely needs to be changed, or perhaps better, removed. For all projects where I make releases, the only mechanism I use to create tags is by running this script: build-aux/do-release-commit-and-tag and I do that only as part of following the procedure described by README-release, e.g., http://git.sv.gnu.org/cgit/coreutils.git/tree/README-release
Re: passfd on more platforms
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 we know from fd if it is a udp or tcp socket ? - if tcp send as OOB - if udp send normally I think that'd be overengineering anyway. With the limitation to SOCK_DGRAM sockets (AF_UNIX for Unix, AF_INET for Win32) your original plan works. Paolo
Re: passfd on more platforms
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 SOCK_DGRAM, using out-of-band data for Windows is not going to work. Could we know from fd if it is a udp or tcp socket ? - if tcp send as OOB - if udp send normally I think that'd be overengineering anyway. With the limitation to SOCK_DGRAM sockets (AF_UNIX for Unix, AF_INET for Win32) your original plan works. Not sure BTW it will be really simple: - send as oob data if fail with WSAEOPNOTSUPP come back to normal send And BTW I will implement emulation of AF_UNIX under mingw using localhost AF_INET socket Bastien Paolo
Re: passfd on more platforms
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 we (should) document it, i.e. on SOCK_DGRAM sockets! Yes and if it fail we will fall back to the normal send, so no fail And BTW I will implement emulation of AF_UNIX under mingw using localhost AF_INET socket That's fine. Paolo
Re: passfd on more platforms
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 implement emulation of AF_UNIX under mingw using localhost AF_INET socket That's fine. Paolo
Re: sigprocmask.c appears to be incompatible w/ system headers
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
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 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! Yes and if it fail we will fall back to the normal send, so no fail So why try in the first place?!? Paolo
Re: passfd on more platforms
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 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! Yes and if it fail we will fall back to the normal send, so no fail So why try in the first place?!? In order to have a working solution for SOCK_STREAM Bastien Paolo
Re: passfd on more platforms
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 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! Yes and if it fail we will fall back to the normal send, so no fail So why try in the first place?!? In order to have a working solution for SOCK_STREAM I'm confused. If we document that sendfd/recvfd only work for SOCK_DGRAM, then why do you want to support SOCK_STREAM? That is, if we are going to document the limitation, then why are you talking about working around the limitation? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: passfd on more platforms
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 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 we (should) document it, i.e. on SOCK_DGRAM sockets! Yes and if it fail we will fall back to the normal send, so no fail So why try in the first place?!? In order to have a working solution for SOCK_STREAM I'm confused. If we document that sendfd/recvfd only work for SOCK_DGRAM, then why do you want to support SOCK_STREAM? That is, if we are going to document the limitation, then why are you talking about working around the limitation? It is easy to have a workable send/recvfd with SOCK_STREAM under unix (except the close problem), so I will implement under windows for SOCK_STREAM -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: passfd on more platforms
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 of course)? And writing a zero byte is out of question for SOCK_STREAM, since you cannot detect message boundaries. Paolo
Re: sigprocmask.c appears to be incompatible w/ system headers
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 make, and see how signal.h is built.
Re: VC-tag again
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 started using maint.mk I had Zile's (much less rigorous) release procedure encoded in a `release' target in its top-level Makefile.am. It seems to me that, much as we're never going to have one size fitting all, having a largely comprehensive release procedure available for projects to use, and having as many as possible actually using it, will be a great time saver for both developers and users. -- http://rrt.sc3d.org
Re: warnings and -Werror
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 set of warnings chosen only apply to certain directories, but not how to make them apply to different targets, AFAICS.) In libidn I have this in my configure.ac: AC_ARG_ENABLE([gcc-warnings], [AS_HELP_STRING([--enable-gcc-warnings], [turn on lots of GCC warnings (for developers)])], [case $enableval in yes|no) ;; *) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;; esac gl_gcc_warnings=$enableval], [gl_gcc_warnings=no] ) if test $gl_gcc_warnings = yes; then gl_WARN_ADD([-Werror], [WERROR_CFLAGS]) ... And in the directories where I want -Werror I add $(WERROR_CFLAGS) to the AM_CPPFLAGS directive. It requires a bit more manual work for package maintainers, so it doesn't feel entirely clean, which is probably the reason it isn't documented better. 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 could just document the current way. I'm not sure. /Simon
Re: sigprocmask.c appears to be incompatible w/ system headers
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 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 make, and see how signal.h is built. --- libgnu/signal.in.h 2011-02-08 03:03:19.0 -0700 +++ libgnu/signal.h 2011-03-11 22:30:27.0 -0700 @@ -1,3 +1,4 @@ +/* DO NOT EDIT! GENERATED AUTOMATICALLY! */ /* -*- buffer-read-only: t -*- vi: set ro: */ /* DO NOT EDIT! GENERATED AUTOMATICALLY! */ /* A GNU-like signal.h. @@ -18,14 +19,14 @@ along with this program. If not, see http://www.gnu.org/licenses/. */ #if __GNUC__ = 3 -@PRAGMA_SYSTEM_HEADER@ +#pragma GCC system_header #endif -@PRAGMA_COLUMNS@ + #if defined __need_sig_atomic_t || defined __need_sigset_t /* Special invocation convention inside glibc header files. */ -# @INCLUDE_NEXT@ @NEXT_SIGNAL_H@ +# include_next signal.h #else /* Normal invocation convention. */ @@ -33,16 +34,327 @@ #ifndef _GL_SIGNAL_H /* The include_next requires a split double-inclusion guard. */ -#@INCLUDE_NEXT@ @NEXT_SIGNAL_H@ +#include_next signal.h #ifndef _GL_SIGNAL_H #define _GL_SIGNAL_H /* The definitions of _GL_FUNCDECL_RPL etc. are copied here. */ +#ifndef _GL_CXXDEFS_H +#define _GL_CXXDEFS_H + +/* The three most frequent use cases of these macros are: + + * For providing a substitute for a function that is missing on some + platforms, but is declared and works fine on the platforms on which + it exists: + + #if @GNULIB_FOO@ + # if !@HAVE_FOO@ + _GL_FUNCDECL_SYS (foo, ...); + # endif + _GL_CXXALIAS_SYS (foo, ...); + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif + + * For providing a replacement for a function that exists on all platforms, + but is broken/insufficient and needs to be replaced on some platforms: + + #if @GNULIB_FOO@ + # if @REPLACE_FOO@ + # if !(defined __cplusplus defined GNULIB_NAMESPACE) + # undef foo + # define foo rpl_foo + # endif + _GL_FUNCDECL_RPL (foo, ...); + _GL_CXXALIAS_RPL (foo, ...); + # else + _GL_CXXALIAS_SYS (foo, ...); + # endif + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif + + * For providing a replacement for a function that exists on some platforms + but is broken/insufficient and needs to be replaced on some of them and + is additionally either missing or undeclared on some other platforms: + + #if @GNULIB_FOO@ + # if @REPLACE_FOO@ + # if !(defined __cplusplus defined GNULIB_NAMESPACE) + # undef foo + # define foo rpl_foo + # endif + _GL_FUNCDECL_RPL (foo, ...); + _GL_CXXALIAS_RPL (foo, ...); + # else + # if !@HAVE_FOO@ or if !@HAVE_DECL_FOO@ + _GL_FUNCDECL_SYS (foo, ...); + # endif + _GL_CXXALIAS_SYS (foo, ...); + # endif + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif +*/ + +/* _GL_EXTERN_C declaration; + performs the declaration with C linkage. */ +#if defined __cplusplus +# define _GL_EXTERN_C extern C +#else +# define _GL_EXTERN_C extern +#endif + +/* _GL_FUNCDECL_RPL (func, rettype, parameters_and_attributes); + declares a replacement function, named rpl_func, with the given prototype, + consisting of return type, parameters, and attributes. + Example: + _GL_FUNCDECL_RPL (open, int, (const char *filename, int flags, ...) + _GL_ARG_NONNULL ((1))); + */ +#define _GL_FUNCDECL_RPL(func,rettype,parameters_and_attributes) \ + _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes) +#define _GL_FUNCDECL_RPL_1(rpl_func,rettype,parameters_and_attributes) \ + _GL_EXTERN_C rettype rpl_func parameters_and_attributes + +/* _GL_FUNCDECL_SYS (func, rettype, parameters_and_attributes); + declares the system function, named func, with the given prototype, + consisting of return type, parameters, and attributes. + Example: + _GL_FUNCDECL_SYS (open, int, (const char *filename, int flags, ...) + _GL_ARG_NONNULL ((1))); + */ +#define _GL_FUNCDECL_SYS(func,rettype,parameters_and_attributes) \ + _GL_EXTERN_C rettype func parameters_and_attributes + +/* _GL_CXXALIAS_RPL (func, rettype, parameters); + declares a C++ alias called GNULIB_NAMESPACE::func + that redirects to rpl_func, if GNULIB_NAMESPACE is defined. + Example: + _GL_CXXALIAS_RPL (open, int, (const char *filename,
Re: warnings and -Werror
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 could just document the current way. I'm not sure. Documenting the current way would certainly be good, as at the moment one is left with the impression that something automatic exists when it doesn't. I think that this use of -Werror is a good one: given that every project will have its list of warnings that it ignores, presumably one does want to check before a release that no active warning flag is generating any warnings. -- http://rrt.sc3d.org
Making releases
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
announcement (AFAICS).
3. It doesn't send the email itself, it emits an email. I can see one
reason for this, namely, it leaves a FIXME: Insert comments. There
are a couple of other odd things about the message, which I reproduce
below for convenience.
First, it has a line from make at the start and end; I presume this is a bug?
Secondly, what's the #secure method=pgpmime mode=sign bit? I presume
this is something to do with signing which I've not seen before? It
doesn't seem to be documented.
Thirdly, why ./NEWS and not NEWS?
It seems this is very close to total automation. I would make a couple
of suggestions:
1. Remove the FIXME. Instead, move the NEWS extract above the
boilerplate. This puts what people most want to read at the top, and
NEWS is a good place to write such comments in any case.
2. Rather than just writing a file, send the email. I suggest a
default setting of mail, with a commented-out setting that instead
opens the mail message in Emacs's composer. (It's a pity that (AFAIK?)
there's no standard GNU launch-URL command to simply open the user's
configured mail composer.) In the default case you could add catting
the message to the terminal. If you do this before uploading the
distribution archive, then the prompt to type one's GPG passphrase
also acts as an OK? (Y/N) point at which the maintainer can bail
out.
It's all about reducing the number of commands that have to be typed
which are always the same.
make[2]: Entering directory `/home/rrt/Software/zile-stable'
To: info-...@gnu.org
Cc: coordina...@translationproject.org, bug-z...@gnu.org
Mail-Followup-To: bug-z...@gnu.org
Subject: zile-2.3.23 released [stable]
#secure method=pgpmime mode=sign
FIXME: put comments here
Here are the compressed sources:
http://ftpmirror.gnu.org/zile/zile-2.3.23.tar.gz (909KB)
Here are the GPG detached signatures[*]:
http://ftpmirror.gnu.org/zile/zile-2.3.23.tar.gz.sig
To reduce load on the main server, use a mirror listed at:
http://www.gnu.org/order/ftp.html
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:
gpg --verify zile-2.3.23.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys 80EE4A00
and rerun the `gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.67
Automake 1.11.1
Gnulib v0.0-4982-ga6bd3da
./NEWS
* Noteworthy changes in release 2.3.23 (2011-03-14)
** Bug fixes
{beginning,end}-of-buffer now take account of transient-mark-mode
(bug present since “forever”).
** Build-related
Turn on more compiler and build system, and run-time checks (thanks,
gnulib!).
make[2]: Leaving directory `/home/rrt/Software/zile-stable'
Re: sigprocmask.c appears to be incompatible w/ system headers
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 expert in.
Re: passfd on more platforms
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, it was hard-coded with Postfix 2.3 for all * platforms because of increasing pressure to work on other things. The * workaround does nothing for 32-bit systems. * * The investigation was reopened with Postfix 2.7 because the workaround * broke with NetBSD 5.0 on 64-bit architectures. This time it was found * that OpenBSD = 4.3 on AMD64 and SPARC64 needed the workaround for * sending only. The following platforms worked with and without the * workaround: OpenBSD 4.5 on AMD64 and SPARC64, FreeBSD 7.2 on AMD64, * Solaris 8 on SPARC64, and Linux 2.6-11 on x86_64. * * As this appears to have been an OpenBSD-specific problem, we revert to * the Postfix 2.2 behavior. Instead of hard-coding the workaround for * all platforms, we now detect sendmsg() errors at run time and turn on * the workaround dynamically. * * The workaround was made run-time configurable to investigate the problem * on multiple platforms. Though set_unix_pass_fd_fix() is over-kill for * this specific problem, it is left in place so that it can serve as an * example of how to add run-time configurable workarounds to Postfix. */ You got this from http://postfix.sourcearchive.com/documentation/2.7.1/unix__send__fd_8c-source.html, right? The workaround there consists in adding some alignment to the msg_controllen field, for the 64-bit case. But here I am testing on NetBSD/i386, and both CMSG_LEN(sizeof(int)) and CMSG_SPACE(sizeof(int)) are 16. I tried all values 4, 8, 12, ..., 32 for msg_controllen - doesn't help. On mingw, I haven't even tried the module. It first requires - a 'socketpair' module for the test, In all the case passing fd is done through socket What do you mean by that? I mean, the test uses the socketpair() function, which mingw doesn't have, so in order to run the test, we must first have socketpair(). Bruno
Re: passfd on more platforms
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, clearing the 'struct iovec' is overkill - or do you know platforms which have more than two fields in 'struct iovec'? Clearing 'msg' is not needed either - it doesn't help on NetBSD 5.0, and on all other platforms, the tests passed without it. Then why add it? Just because http://postfix.sourcearchive.com/documentation/2.7.1/unix__send__fd_8c-source.html has it? Bruno
Re: passfd on more platforms
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. 2) Because passing file descriptors implies a conversion step (that happens in the kernel), and a unit test that only uses two threads doesn't exercise this essential part of the functionality: If the conversion step was missing, the test wouldn't notice. Bruno
Re: sigprocmask.c appears to be incompatible w/ system headers
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 exitfail.lo localcharset.lo malloca.lo openat-die.lo progname.lo sockets.lo strnlen1.lo asnprintf.lo basename-lgpl.lo chdir-long.lo cloexec.lo dirname-lgpl.lo dup-safer.lo fcntl.lo fd-safer.lo filemode.lo getcwd.lo getopt.lo getopt1.lo glob.lo md5.lo nanosleep.lo openat-proc.lo pipe-safer.lo printf-args.lo printf-parse.lo save-cwd.lo strftime.lo stripslash.lo tempname.lo vasnprintf.lo -lm There is no sigprocmask.lo in this list. This is normal; gnulib's sigprocmask.c is not compiled on glibc systems. You can see from the gnulib documentation http://www.gnu.org/software/gnulib/manual/html_node/sigprocmask.html that this source file is only compiled on mingw platforms. Also, the generated signal.h is built with HAVE_SIGSET_T being replaced with 1, therefore it does not redefine the 'sigset_t' type. In https://savannah.gnu.org/bugs/?30685 you write: A change (similar to Leonardo's) that seems to work while theoretically maintaining sigaction functionality is to explicitly call the sigemptyset macro (bits/sigset.h): octave-3.4.0/src/sighandlers.cc line 225 //gnulib::sigemptyset (act.sa_mask); //gnulib::sigemptyset (oact.sa_mask); //gnulib::sigaction (sig, act, oact); __sigemptyset (act.sa_mask); __sigemptyset (oact.sa_mask); sigaction (sig, act, oact); (only removing the namespace didn't work for me either) This indicates that the crucial difference is between the __sigemptyset macro and the sigemptyset functions, both from glibc. Or if 'sigemptyset' would work fine, then the crucial difference would be in the function pointer indirection by which gnulib implements the 'gnulib::sigemptyset' function in term of the 'sigemptyset' function pointer. In order to debug this, I would recommend to look at - the source code of the __sigemptyset macro and of the sigemptyset function, - the assembly level instructions where it crashes: #0 0xb785896c in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so because it's not clear why liboctinterp-3.3.53.so would contain a sigemptyset function at all (since gnulib's one is not being compiled). - the preprocessed source file (g++ -E -dD) of the compilation unit that contains the gnulib::sigemptyset invocation. Bruno
