Date: Sat, 20 Aug 2005 10:16:52 +0200 From: Stefan Farfeleder <stefanf@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: <pthread.h> includes Message-ID: <20050820081649.GA85488@wombat.fafoe.narf.at> In-Reply-To: <20050820151252.L60332@delplex.bde.org> References: <20050819093649.GU21905@wombat.fafoe.narf.at> <20050819231640.E2640@epsplex.bde.org> <20050819183507.GE77069@wombat.fafoe.narf.at> <20050820151252.L60332@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 20, 2005 at 03:48:31PM +1000, Bruce Evans wrote: > 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. > %%% That's what I have here too. [...] > >>... > >><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. Do you have a better suggestion? > >><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. I agree that <limits.h> is missing the PTHREAD_{DESTRUCTOR_ITERATIONS,KEYS_MAX,STACK_MIN,THREADS_MAX} macros. It's not an error for <pthread.h> to define them because POSIX reserves pthread_* and PTHREAD_* for this header. I'm not sure why MINSIGSTKSZ (which expands to const * 4 on all architectures) is not a constant. What do you think about putting __MINSIGSTKSZ in <machine/_limits.h>? > >><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. Which _SC_THREAD* is missing? Calling sysconf() with _SC_THREAD_THREADS_MAX is buggy because sysconf converts ULONG_MAX to a long. Stefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050820081649.GA85488>