From owner-freebsd-hackers Wed Feb 26 23:54:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA11298 for hackers-outgoing; Wed, 26 Feb 1997 23:54:09 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA11288; Wed, 26 Feb 1997 23:54:03 -0800 (PST) From: Mike Pritchard Message-Id: <199702270754.XAA11288@freefall.freebsd.org> Subject: Re: sig*set macros in To: bde@zeta.org.au (Bruce Evans) Date: Wed, 26 Feb 1997 23:54:02 -0800 (PST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199702270421.PAA13463@godzilla.zeta.org.au> from "Bruce Evans" at Feb 27, 97 03:21:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >Is there a good reason for having the sig*set macros defined > >in 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"