From owner-freebsd-hackers  Wed Feb 26 20:27:14 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA01837
          for hackers-outgoing; Wed, 26 Feb 1997 20:27:14 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01828;
          Wed, 26 Feb 1997 20:27:09 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id PAA13463; Thu, 27 Feb 1997 15:21:55 +1100
Date: Thu, 27 Feb 1997 15:21:55 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702270421.PAA13463@godzilla.zeta.org.au>
To: freebsd-hackers@freefall.freebsd.org, mpp@freefall.freebsd.org
Subject: Re: sig*set macros in <signal.h>
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>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