Re: Feature Request: define sighandler_t

[Eric Blake]

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 'signal-gnu', since this GNU extension does not conflict with
> POSIX.

"Technically", POSIX reserves all names ending in _t for future
standardization, so exposing sighandler_t is a violation of POSIX in
that respect (and explains why glibc does not expose the name when
!_GNU_SOURCE).  But in all practicality, POSIX will not standardize a
name ending in _t unless it either matches existing practice (bringing
previous violations into compliance) or is unlikely to conflict, and
even if POSIX did introduce a sighandler_t with a different meaning that
glibc's current use, I'm sure that both glibc and gnulib would adapt
pretty quickly if we can't convince POSIX to not make the change.

> So here's a proposed patch:
> 
> 
> 2011-05-03  Bruno Haible  <address@hidden>
> 
>       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 sighandler_t is defined.
>       (gl_SIGNAL_H_DEFAULTS): Initialize HAVE_SIGHANDLER_T.
>       * modules/signal (Depends-on): Add extensions.
>       (Makefile.am): Substitute HAVE_SIGHANDLER_T.
>       * doc/posix-headers/signal.texi: Mention the problem with sighandler_t.
>       Suggested by Markus Steinborn <address@hidden>.

Works for me.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature