This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: signal.h: sighandler_t
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