Date: Thu, 26 Dec 1996 15:20:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: kern/2279: questionable parameter types in /usr/include/signal.h Message-ID: <199612262320.PAA15980@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612262320.PAA15980>