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 <br...@clisp.org> > > 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 <gnugv_maintai...@yahoo.de>. Works for me. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
