Date: Thu, 26 Dec 1996 10:40:01 -0800 (PST) From: "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi> To: freebsd-bugs Subject: Re: kern/2279: questionable parameter types in /usr/include/signal.h Message-ID: <199612261840.KAA01992@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/2279; it has been noted by GNATS.
From: "Jukka A. Ukkonen" <jau@jau.tmt.tele.fi>
To: bde@zeta.org.au (Bruce Evans)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/2279: questionable parameter types in /usr/include/signal.h
Date: Thu, 26 Dec 1996 20:32:53 +0200 (EET)
Quoting Bruce Evans:
>
> >>Description:
> >
> > See the patch below in the Fix section.
>
> 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.
Macros within the parameter lists of prototypes will probably one
day cause more problems than importing some definitions one does
not absolutely need at the time.
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
That should save you at least from doing useless duplicated typedefs.
On the other hand I guess there is no way of importing only those
typedefs that are absolutely needed. Making everything the way STDC
and POSIX put it one is bound to always get some "crap" with the
typedefs one really needs.
> >--- /usr/include/signal.h.orig Thu Dec 26 00:01:31 1996
> >+++ /usr/include/signal.h Wed Dec 25 23:55:02 1996
> >@@ -36,6 +36,7 @@
> > #ifndef _SIGNAL_H_
> > #define _SIGNAL_H_
> >
> >+#include <sys/types.h>
>
> 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.
Cheers,
// jau
------
/ Jukka A. Ukkonen, Internet and New Media / Finnish Telecom Ltd.
/__ M.Sc. (sw-eng & cs) (Phone) +358-2040-4025
/ Internet: Jukka.Ukkonen@tele.fi (Fax) +358-2040-2712
/ Internet: jau@iki.fi (Mobile) +358-400-606671
v Internet: ukkonen@nic.funet.fi (Home&Fax) +358-9-6215280
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612261840.KAA01992>