Re: Feature Request: define sighandler_t

Markus Steinborn wrote: > Works well on RHEL 5 (-Clones) and on Mac OS X. Thanks for your testing. I've committed the patch now. Bruno -- In memoriam Peter van Pels

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: 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

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