Date: Wed, 26 Feb 1997 23:54:02 -0800 (PST) From: Mike Pritchard <mpp> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: sig*set macros in <signal.h> Message-ID: <199702270754.XAA11288@freefall.freebsd.org> In-Reply-To: <199702270421.PAA13463@godzilla.zeta.org.au> from "Bruce Evans" at Feb 27, 97 03:21:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > >Is there a good reason for having the sig*set macros defined > >in <signal.h> and the equivalent functions in libc? > > Yes. ANSI requires function versions for almost all function-like > interfaces, so that applications can use the function version if > necessary (*). sig*set are POSIX functions, not ANSI. I'm not sure > if POSIX has the same rule, but it's a good rule. > > (*) The function version is necessary for calls through a function > pointer. For the few function-like interfaces that may have side > effects on their args, the function version is necessary for avoiding > side effects. > > >The macros > >are only defined if _ANSI_SOURCE isn't. > > Neither are prototypes for the sig*set functions declared. This is > because they aren't ANSI functions. > > >Plus it doesn't looks like > >they are used that much anyways (about 2 dozen programs). > > This is because most programs in /usr/src that use signals assume BSD > signal semantics, so they can get away with using signal() instead of > sigaction(). > > Bruce Let's try this again. Can we remove the macro definitions, and just rely on the functions? -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702270754.XAA11288>