Date: Sat, 20 Aug 2005 15:48:31 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Farfeleder <stefanf@FreeBSD.org> Cc: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: <pthread.h> includes Message-ID: <20050820151252.L60332@delplex.bde.org> In-Reply-To: <20050819183507.GE77069@wombat.fafoe.narf.at> References: <20050819093649.GU21905@wombat.fafoe.narf.at> <20050819231640.E2640@epsplex.bde.org> <20050819183507.GE77069@wombat.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Aug 2005, Stefan Farfeleder wrote: > On Sat, Aug 20, 2005 at 12:04:56AM +1000, Bruce Evans wrote: >> On Fri, 19 Aug 2005, Stefan Farfeleder wrote: >> >>> I think some of the headers included by <pthread.h> violate the POSIX >>> specification (I'm looking at SUSv3/POSIX 1003.1 2004) by making more >>> symbols visible than allowed. >>> >>> <sys/cdefs.h> Ok >>> <sys/types.h> Ok >>> <sys/_pthreadtypes.h> Ok >>> <sys/time.h> No? (POSIX allows <time.h> which is a subset) > ^^^^^^ > Actually POSIX kind of requires the inclusion of <time.h> (and > <sched.h>). At least all symbols must be visible. Urk. This seems to be the place in POSIX where namespace pollution is explictly required. According to an old draft: %%% 10351 Inclusion of the <pthread.h> header shall make symbols defined in the headers <sched.h> and 10352 <time.h> visible. %%% Everywhere else, POSIX permits both broken and non-broken implementations by saying "may make visible". The history of this is interesting: %%% 10408 IEEE PASC Interpretation 1003.1 #86 is applied, allowing the symbols from <sched.h> and 10409 <time.h> to be made visible when <pthread.h> is included. Previously this was an XSI 10410 extension. %%% The weasels who wrote "may" were apparently not present when this was interpreted :-). %%% 10411 IEEE PASC Interpretation 1003.1c #42 is applied, removing the requirement for prototypes for 10412 the pthread_kill ( ) and pthread_sigmask( ) functions. These are required to be in the <signal.h> 10413 header. They are allowed here through the name space rules. %%% sigset_t apparently isn't required here either. >> <sys/cdefs.h> needed, but can be obtained as a side effect >> of including almost any other header in the list. >> <sys/types.h> only used to declare size_t. We handle this better >> in many other headers. The old draft of POSIX that >> I'm looking at doesn't say that <pthread.h> declares >> size_t, so it might be conformant to use __size_t >> in the prototypes. > > Removed, size_t is obtained via <time.h>. OK. >> ... >> <sys/time.h> only used to declare sigset_t and struct timespec. >> We have a whole header, <sys/_sigset.h>, to help >> declare sigset_t better (it only declares >> __sigset_t), > ... > I've include <machine/_types.h> (for __uint32_t) and <sys/_sigset.h> > instead. timespec is declared through <time.h>. Too bad. >> <sys/signal.h> Just namespace pollution. > > We need MINSIGSTKSZ from <machine/signal.h> though. The patch includes > that header instead and protects its usage with __XSI_VISIBLE. I'm not > happy with this, maybe MINSIGSTKSZ should be moved somewhere else? MINSIGSTKSZ is used to define PTHREAD_STACK_MIN. I didn't notice this partly because the old version that I looked at correctly defiens PTHREAD_STACK_MIN as a constant. Everything is wrong here: - POSIX requires PTHREAD_STACK_MIN to be defined (if at all) in <limits.h> but not in <pthread.h>. - PTHREAD_STACK_MIN must be defined as a number (if at all even if XSI is no visible. >> <limits.h> Just namespace pollution. > > <machine/_limits.h> is included instead and __ULONG_MAX is used. __ULONG_MAX is used to define PTHREAD_THREADS_MAX. POSIX actually requires the latter to be defined (if at all) in <limits.h> only too. I doubt that the limit is actually 2^64-1. Maybe it should be a runtime limit _SC_THREAD* are missing, so apparently no one ever asks for the runtime limits. >> <sched.h> only used to declare struct sched_param and to >> satisfy a POSIX mistake. A forward declaration >> would suffice. > > Left because POSIX says so. Not too bad. > The patch for <pthread.h> is at > http://people.freebsd.org/~stefanf/pthread.h.diff . > > There are a few files that need <sys/types>, <limits.h>, etc symbols and > get them by <pthread.h> inclusion, the patch at > http://people.freebsd.org/~stefanf/pthread.h-2.diff fixes that. It > should probably be committed anyway. An alarming number. We shouldn't need so many new includes of <sys/types.h>, Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050820151252.L60332>