Jeff King wrote: > I don't think your patch is the right solution, but FWIW, sigchain was > explicitly intended to be able to take SIG_DFL and SIG_IGN. Probably > sigchain_fun should be removed and we should just use sighandler_t > explicitly Sorry, that was lazy of me. The name sighandler_t is a GNU extension[1]. The following addresses my confusion but I doubt it's worth the syntactic ugliness. -- 8< -- Subject: sigchain: hide sigchain_fun type Signal handlers that might be passed to signal() must be pointers to function with the prototype void handler(int signum); In glibc this type is called sighandler_t; in the sigchain lib, sigchain_fun. These really represent the same type in all respects: even special values like SIG_IGN and SIG_DFL are perfectly reasonable arguments for a function accepting values of one of the two types. Avoid confusion by eliminating the sigchain_fun name from sigchain.h. It would be nice to instead use sighandler_t everywhere, but unfortunately that name is a GNU extension. Suggested-by: Jeff King <peff@xxxxxxxx> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> --- [1] http://www.delorie.com/gnu/docs/glibc/libc_481.html sigchain.c | 2 ++ sigchain.h | 6 ++---- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sigchain.h b/sigchain.h index 618083b..571d148 100644 --- a/sigchain.h +++ b/sigchain.h @@ -1,11 +1,9 @@ #ifndef SIGCHAIN_H #define SIGCHAIN_H -typedef void (*sigchain_fun)(int); - -int sigchain_push(int sig, sigchain_fun f); +int sigchain_push(int sig, void (*f)(int)); int sigchain_pop(int sig); -void sigchain_push_common(sigchain_fun f); +void sigchain_push_common(void (*f)(int)); #endif /* SIGCHAIN_H */ diff --git a/sigchain.c b/sigchain.c index 1118b99..f837f61 100644 --- a/sigchain.c +++ b/sigchain.c @@ -3,6 +3,8 @@ #define SIGCHAIN_MAX_SIGNALS 32 +typedef void (*sigchain_fun)(int); + struct sigchain_signal { sigchain_fun *old; int n; -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html