Re: Feature Request: define sighandler_t

Hi Bruno, Bruno Haible schrieb: So here's a proposed patch: Thank you very much. 2011-05-03 Bruno Haible signal: Define sighandler_t. * lib/signal.in.h (sighandler_t): New type. * m4/signal_h.m4 (gl_SIGNAL_H): Require AC_USE_SYSTEM_EXTENSIONS. Test whether

Re: Todo for libposix branch?

Hi Reuben, Bruce, On Tue, May 03, 2011 at 04:56:33PM -0700, Bruce Korb wrote: > On 05/03/11 15:45, Reuben Thomas wrote: > >Is there a public todo for the libposix branch? If so, could it go in > >the branch somewhere visible? It's all in the mailing list archives, but summarizing the current stat

Re: Todo for libposix branch?

Hi Reuben, > Is there a public todo for the libposix branch? The TODO items are the following: 1) ... 7) proposed by Gary in the thread starting at [PATCH 0/7] contents of topic/libposix for merge to master in Status:

Re: gnulib's licensing

Hi Reuben, > licensing, dependency on autotools, source library > ... > Of those three defects, the third is now being addressed (at least, > for POSIX APIs, by libposix), and the second is not particularly > urgent (autotools has a much bigger reach than it had 6 years ago, and > has less competi

Re: Todo for libposix branch?

On 05/03/11 15:45, Reuben Thomas wrote: Is there a public todo for the libposix branch? If so, could it go in the branch somewhere visible? If not, is there any way I can help gather up the material for one? I'm keen now to see libposix a reality, so I'd like to see what still needs to be done to

Re: gnulib's licensing

On 05/03/11 16:08, Reuben Thomas wrote: > I assume the licensing for gnulib arises from standard GNU policy; I > just wonder if the portability parts may be a case for an exception. A few parts of gnulib are so trivial that they could perhaps be made exceptions. I think it unlikely, though, that

gnulib's licensing

I just found a reference to Diego Pettenò's article about gnulib: http://www.linux.com/archive/articles/50702 Its summary section is quite interesting, because despite being written six years ago, it still lists what I see as the main defects of gnulib (licensing, dependency on autotools, source l

Todo for libposix branch?

Is there a public todo for the libposix branch? If so, could it go in the branch somewhere visible? If not, is there any way I can help gather up the material for one? I'm keen now to see libposix a reality, so I'd like to see what still needs to be done to get it in master. -- http://rrt.sc3d.or

Re: what happened to HAVE_STDBOOL_H

On 05/03/2011 04:34 PM, Sam Steingold wrote: >> is not required by C89. However, nothing else in gnulib >> used the results of the test, and the idea is that if you are using >> gnulib's stdbool module, you don't care about a fully >> standards-compliant , rather you care about the subset of >>

Re: what happened to HAVE_STDBOOL_H

> * Eric Blake [2011-05-03 16:03:16 -0600]: > > On 05/03/2011 03:52 PM, Sam Steingold wrote: >> when I regenerate config.h with the current gnulib, I get: >> >> @@ -871,12 +979,6 @@ >> /* `struct sockaddr_un' from has a `sun_len' field */ >> #undef HAVE_SOCKADDR_UN_LEN >> >> -/* Define to 1

Re: what happened to HAVE_STDBOOL_H

On 05/03/2011 03:52 PM, Sam Steingold wrote: > when I regenerate config.h with the current gnulib, I get: > > @@ -871,12 +979,6 @@ > /* `struct sockaddr_un' from has a `sun_len' field */ > #undef HAVE_SOCKADDR_UN_LEN > > -/* Define to 1 if stdbool.h conforms to C99. */ > -#undef HAVE_STDBOOL_

Re: question about correct usage of gnulib

Lorenzo Bettini asked: > >> Would it be correct to put config.h only say in file1.cpp (and use the > >> ‘-I’ option that refers to the Gnulib library directory for that file > >> only), and not in file2.cpp and file3.cpp (where I don't use -I to refer > >> to gnulib library directory), and then lin

what happened to HAVE_STDBOOL_H

when I regenerate config.h with the current gnulib, I get: @@ -871,12 +979,6 @@ /* `struct sockaddr_un' from has a `sun_len' field */ #undef HAVE_SOCKADDR_UN_LEN -/* Define to 1 if stdbool.h conforms to C99. */ -#undef HAVE_STDBOOL_H - -/* Define to 1 if you have the header file. */ -#undef

Re: [PATCH 1/2] conditional dependencies between modules

No comments in two days, so I pushed the two patches. If you notice some oddities with --conditional-dependencies, please report them as gnulib bugs. Hopefully we can move this feature from "experimental" to stable status soon. Bruno -- In memoriam Zbigniew Iwański

[PATCH] test-getaddrinfo: report error information

Clang deduced that if ENABLE_DEBUGGING is undefined, then err was a dead assignment. But in the EAI_SYSTEM case, we fail the test, so the output should be unconditional. * tests/test-getaddrinfo.c (simple): Use err outside of dbprintf. Signed-off-by: Eric Blake --- ChangeLog|

Re: sed hangs on solaris

Paul Eggert wrote: > If my diagnosis is right, then yes, it's be a fairly serious kernel bug > that really should get fixed It may also be a shell bug (if the shell passes wrong arguments to the child processes, or if it does not close the pipe descriptors in the parent process). Jim had another

Re: Feature Request: define sighandler_t

On 05/03/2011 02:58 PM, Bruno Haible wrote: >> Could you define sighandler_t in the signal package iff _GNU_SOURCE is >> defined? > > In gnulib, we tend to make GNU extensions available unconditionally but > possibly in a separate module. But I don't see the point of having an > extra module 'sig

Re: Feature Request: define sighandler_t

Hi Markus, > the man-page signal(2) tells me (at least on my system): > > typedef void (*sighandler_t)(int); > > The use of sighandler_t is a GNU extension. ... > > Could you define sighandler_t in the signal package iff _GNU_SOURCE is > defined? In gnulib, we tend to make GNU

Re: sed hangs on solaris

On 05/03/11 13:26, Sam Steingold wrote: > note that some pipelines appear to succeed before the hanging: Yes. If it is a kernel bug, quite possibly it's timing-dependent, and I wouldn't be surprised if it's not that common.

Re: sed hangs on solaris

> * Paul Eggert [2011-05-03 13:13:03 -0700]: > > On 05/03/11 13:00, Sam Steingold wrote: >>> > So, we have (sed X | sed Y | sed Z), and sed X is sleeping waiting >>> > for its write to finish, while sed Y is sleeping waiting for its >>> > read to finish. I'm not sure, but this would appear to be

Re: sed hangs on solaris

On 05/03/11 13:00, Sam Steingold wrote: >> > So, we have (sed X | sed Y | sed Z), and sed X is sleeping waiting >> > for its write to finish, while sed Y is sleeping waiting for its >> > read to finish. I'm not sure, but this would appear to be >> > a kernel bug in Solaris 11. > that sucks. > so,

Re: sed hangs on solaris

> 21663:execve("/usr/gnu/bin/sed", 0x08067DA8, 0x08073BA0) argc = 91 > ... > 21665:execve("/usr/gnu/bin/sed", 0x08073508, 0x08073BA0) argc = 81 > ... > 21667:execve("/usr/gnu/bin/sed", 0x080739E4, 0x08073BB4) argc = 33 > ... > 21665:read(0, 0xFEF59FD8, 1024)

Re: sed hangs on solaris

On 05/03/11 10:14, Sam Steingold wrote: > whan do I do now? Maybe run "truss"? What does "truss -f -o truss.txt make" put into "truss.txt"?

do-release-commit-and-tag requires that I be on master branch?

But I'm trying to make an alpha release, which is on a different branch, so that I can carry on making stable releases from master until the new version is ready. Suggestions? -- http://rrt.sc3d.org

Feature Request: define sighandler_t

Hi everybody, the man-page signal(2) tells me (at least on my system): typedef void (*sighandler_t)(int); The use of sighandler_t is a GNU extension. Various versions of libc predefine this type; libc4 and libc5 define SignalHandler, glibc defines sig_t

sed hangs on solaris

SunOS 5.11 snv_134 i86pc i386 i86pc Solaris make hangs: rm -f unistd.h-t unistd.h && \ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's|@''HAVE_UNISTD_H''@|1|g' \ -e 's|@''INCLUDE_NEXT''@|include_next|g' \ -e 's|@''PRAGMA_SYSTEM_HEADER'

Re: RFC socketpair

On 05/03/2011 03:07 PM, Bastien ROUCARIES wrote: It seems that we could use DuplicateHandle for the same process see http://support.microsoft.com/kb/150523/en-us Nice! Paolo

Re: RFC socketpair

It seems that we could use DuplicateHandle for the same process see http://support.microsoft.com/kb/150523/en-us Bastien On Tue, May 3, 2011 at 3:00 PM, Bastien ROUCARIES wrote: > On Mon, May 2, 2011 at 3:52 PM, Paolo Bonzini wrote: >> On 05/01/2011 04:29 PM, Bastien ROUCARIES wrote: >>> >>> Di

Re: RFC socketpair

On Mon, May 2, 2011 at 3:52 PM, Paolo Bonzini wrote: > On 05/01/2011 04:29 PM, Bastien ROUCARIES wrote: >> >> Did you test if dup2 work for socket ? >> >> According tohttp://www.suacommunity.com/dictionary/dup-entry.php >> andhttp://blog.csdn.net/linlu11/archive/2008/06/06/2518571.aspx  it >> will

Re: [PATCH] fclose: reduce dependencies

Eric Blake writes: > In a non-GPL project, the last change to fclose dragged in > inappropriate modules. > > * modules/fclose (Depends-on): Switch from fflush/fseeko to > simpler lseek. > * lib/fclose.c (rpl_fclose): Likewise. > Reported by Simon Josefsson. Thanks. It works for me. /Simon

Re: question about correct usage of gnulib

On 05/02/2011 02:59 PM, Bastien ROUCARIES wrote: On Mon, May 2, 2011 at 12:02 PM, Lorenzo Bettini wrote: On 04/25/2011 06:36 PM, Bruno Haible wrote: Lorenzo Bettini wrote: on the manual I read "These Gnulib substitute header files rely onbeing already included. Furthermoremust be

Re: remove 'exit'?

Eric Blake writes: > On 05/02/2011 12:47 AM, Simon Josefsson wrote: >> k...@freefriends.org (Karl Berry) writes: >> >>> FWIW, I also agree with just removing the module instead of trying to >>> ever-escalate warnings. My experience is that few people are likely to >>> deal with it until it beco

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

On 05/03/11 00:09, Gary V. Vaughan wrote: > However, I'm still none-the-wiser over what needs changing in gnulib > to take this into account correctly. What is the output of gcc -E -dU test-stdint.c? That may help you debug who defines what where.

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

Hi Paul, On Mon, May 02, 2011 at 09:24:46AM -0700, Paul Eggert wrote: > On 05/02/11 05:09, Gary V. Vaughan wrote: > >> example, it could be that (which intprops.h includes) > >> > redefines UINT_FAST8_MAX to the wrong value. > > That seems to me to be what is happening. Is this something that gn