signal.h: sighandler_t

[Corinna Vinschen]

On Jul  1 10:50, Howland Craig D (Craig) wrote:
> > From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Corinna Vinschen
> > Sent: Thursday, July 01, 2010 4:51 AM
> > On Jul  1 01:38, Yaakov S wrote:
> > > glibc uses the name sighandler_t for the signal handler function
> > > type[1].  Patch attached which provides this typedef without
> changing
> > > the existing _sig_func_ptr naming.
> > > [...]
> > > 	* libc/include/signal.h (sighandler_t): Add typedef.
> > 
> > Thanks, applied (really!)
> > 
> > Corinna
>  
> To be picky:  namespace violation.  sighandler_t is neither C nor POSIX,
> and is clearly identified as a GNU extension in the reference that
> Yaakov supplied.
>  
> The GLIBC that I can easily check (on RHEL3) does not unconditionally
> declare sighandler_t, confirming my complaint.  It has:
>  
> #ifdef __USE_GNU
> typedef __sighandler_t sighandler_t;
> #endif
> /* 4.4 BSD uses the name `sig_t' for this.  */
> #ifdef __USE_BSD
> typedef __sighandler_t sig_t;
> #endif
> ...
> /* Type of a signal handler.  */
> typedef void (*__sighandler_t) (int);
>  
> I would suspect that newer GLIBCs use the same construct.  If we want
> to emulate some of the GLIBC extensions, we should also be using some
> kind of conditional.  A natural thing would be to simply use the same
> __USE_GNU that they do (although I have not followed it to see how
> it gets defined--a first-order guess is that the user needs to give it
> to the compiler).  But we should consider and choose a mechanism for
> GLIBC extension support intstead of simply falling into one.

Maybe we should simply use `#ifndef _POSIX_SOURCE' for now.  We have no
header file based mechanism in place right now, which would allow a
finer grained control over the namespace.  In glibc that's basically
done in /usr/include/features.h.  Adding this to newlib is not a small
task.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat