From owner-freebsd-bugs  Thu Dec 26 15:20:05 1996
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id PAA15996
          for bugs-outgoing; Thu, 26 Dec 1996 15:20:05 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id PAA15980;
          Thu, 26 Dec 1996 15:20:02 -0800 (PST)
Date: Thu, 26 Dec 1996 15:20:02 -0800 (PST)
Message-Id: <199612262320.PAA15980@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: kern/2279: questionable parameter types in /usr/include/signal.h
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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

From: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, jau@jau.tmt.tele.fi
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/2279: questionable parameter types in /usr/include/signal.h
Date: Fri, 27 Dec 1996 10:06:52 +1100

 >> THere was no bug.  _BSD_PID_T is defined in <machine/ansi.h>.
 >
 >	No, not a functional bug, but a logic one. For logical completeness
 >	it should read pid_t as per definition instead of _BSD_PID_T_ which
 >	is not a real type from the compiler's point of view, but just a
 >	macro which is later undefined when the real pid_t gets defined.
 
 No, the macro is never undefined.  See <machine/ansi.h>.
 
 >	I always liked the ConvexOS way of doing these #defines and typedefs.
 >	ConvexOS also has something like _BSD_PID_T_ macros which are used
 >	for initial typedefs. All the typedef types are then declared as
 >
 >	#ifndef	_PID_T
 >	typedef _BSD_PID_T_	pid_t;
 >	#  define _PID_T	pid_t
 >	#endif
 
 This way takes more code and is only necessary for types that must be
 declared in multiple headers (like size_t).
 
 >> This restores the massive namespace pollution that I fixed in rev.1.4.
 >> Note that <sys/signal.h> is included unconditionally by <signal.h>, so
 >> it must be just as careful about namespace pollution as <signal.h>.
 >
 >	Eh? So... what has <sys/signal.h> to do with it? It has nothing
 >	to do with defining pid_t. At least it shouldn't have.
 
 I thought you were fixing <sys/signal.h>.  It's more obviously wrong to
 include <sys/types.h> in <signal.h> than in <sys/signal.h> :-).
 <sys/signal.h> used to include it.
 
 Bruce