Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!longway!std-unix
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.std.unix
Subject: Re: ANSI vs POSIX on <sys/types.h>
Message-ID: <714@longway.TIC.COM>
Date: 1 Jun 90 15:45:20 GMT
References: <711@longway.TIC.COM> <712@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 33
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From:  Andy Tanenbaum <ast@cs.vu.nl>

In article <712@longway.TIC.COM> Doug Gwyn <gwyn@smoke.brl.mil> writes:
><signal.h> must not define extra garbage such as the kill() interface
>or the POSIX *_t typedefs, except under control of some "feature test
>macro" such as _POSIX_SOURCE.  In the case of the typedefs, I would
>urge that they not be defined as a side effect of #including <signal.h>
>even in the presence of _POSIX_SOURCE.  You don't need pid_t to properly
>declare getpid() or kill() in an implementation; instead, simply use the
>equivalent type derived from basic types (in this case, probably "int").

POSIX specifically defines kill's first argument as type pid_t, so it
would seem to be poor programming practice to use int, even if this is legal.
If one replaced the *_t types by their definitions everywhere, then a
decision to change pid_t from, say, int, to, say, long, would require
a real expert to dig through all the code to find those int's that really
are pid_t's.  Maintenance of such code would be exceedingly difficult.
I think that the only realistic way is to use pid_t in the prototype of 
kill.  This prototype is required in <signal.h> (protected by
#ifdef _POSIX_SOURCE).

This then raises the question of how to make pid_t known.  In the example
implementation given, <sys/types.h> is included in raise.c.  If this is
indeed legal, then that is clearly one way to do it, as presumably all the
names introduced by <sys/types.h> are not present in the object file,
raise.o, and thus do not pollute the name space.

However, why do you urge not to put #include <sys/types.h> into <signal.h>
under protection of #ifdef _POSIX_SOURCE?

Andy Tanenbaum (ast@cs.vu.nl)

Volume-Number: Volume 20, Number 23