This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: signal.h: sighandler_t


> 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.
 
Craig


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]