kern/104436: [PATCH] sys/sem.h should include sys/types.h

[John Baldwin]

The following reply was made to PR kern/104436; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: Bruce Evans <bde at zeta.org.au>
Cc: Cheng-Lung Sung <clsung at freebsd.org>, FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/104436: [PATCH] sys/sem.h should include sys/types.h
Date: Thu, 19 Oct 2006 10:39:59 -0400

 On Tuesday 17 October 2006 20:09, Bruce Evans wrote:
 > On Tue, 17 Oct 2006, John Baldwin wrote:
 > 
 > > How's this, it removes extra includes of cdefs.h and _types.h (ipc.h
 > > already includes them), moves the typedefs earlier and includes them
 > > in the _KERNEL case (consistent with ipc.h) and fixes the whitespace
 > > in the typedefs.
 > 
 > OK.  POSIX actually requires the namespace pollution with everything in
 > sys/ipc.h, so the include of this can't be cleaned up and we may as well
 > depend on its internals.
 
 I've committed it.
 
 > I did a quick review of symbols in sys/sem.h:
 > - POSIX seems to overspecify the representation: "A semaphore shall be
 >    respresented by an anonymous struct containing the following members:"
 >    [semval, sempid, semncnt, semzcnt]".  FreeBSD doesn't declare any of
 >    these struct members.
 
 It does, but 'struct sem' is private to kern/sysv_sem.c:
 
 struct sem {
         u_short semval;         /* semaphore value */
         pid_t   sempid;         /* pid of last operation */
         u_short semncnt;        /* # awaiting semval > cval */
         u_short semzcnt;        /* # awaiting semval = 0 */
 };
 
 > - FreeBSD declares several things that aren't required by POSIX and uses
 >    bad names for most of these.  The worst ones are the struct member
 >    names `val', `buf' and `array'.  POSIX cannot reserve these, and sem.h
 >    mostly uses a `sem' prefix to avoid such pollution.  These seem to be
 >    implementation details that don't belong in the header anyway.
 
 Hmm the 'semun' union is actually passed as an arg to semctl() and the names
 it uses seem to be standard as Linux, etc. use the same name.
 
 > I didn't check the symbols imported from sys/ipc.h.  Both of these headers
 > are XSI extensions, so they don't need many visibility ifdefs internally.
 
 -- 
 John Baldwin