From owner-freebsd-threads@FreeBSD.ORG Sat Aug 20 08:16:56 2005 Return-Path: X-Original-To: threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A56C16A41F; Sat, 20 Aug 2005 08:16:56 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from viefep17-int.chello.at (viefep17-int.chello.at [213.46.255.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBEC843D45; Sat, 20 Aug 2005 08:16:54 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep17-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050820081652.NMUC1234.viefep17-int.chello.at@wombat.fafoe.narf.at>; Sat, 20 Aug 2005 10:16:52 +0200 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id BAF5C2FF; Sat, 20 Aug 2005 10:16:52 +0200 (CEST) Date: Sat, 20 Aug 2005 10:16:52 +0200 From: Stefan Farfeleder To: Bruce Evans Message-ID: <20050820081649.GA85488@wombat.fafoe.narf.at> Mail-Followup-To: Bruce Evans , threads@FreeBSD.org, standards@FreeBSD.org References: <20050819093649.GU21905@wombat.fafoe.narf.at> <20050819231640.E2640@epsplex.bde.org> <20050819183507.GE77069@wombat.fafoe.narf.at> <20050820151252.L60332@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050820151252.L60332@delplex.bde.org> User-Agent: Mutt/1.5.9i Cc: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: includes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2005 08:16:56 -0000 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 violate the POSIX > >>>specification (I'm looking at SUSv3/POSIX 1003.1 2004) by making more > >>>symbols visible than allowed. > >>> > >>> Ok > >>> Ok > >>> Ok > >>> No? (POSIX allows which is a subset) > > ^^^^^^ > >Actually POSIX kind of requires the inclusion of (and > >). 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 header shall make symbols > defined in the headers and > 10352 visible. > %%% That's what I have here too. [...] > >>... > >> only used to declare sigset_t and struct timespec. > >> We have a whole header, , to help > >> declare sigset_t better (it only declares > >> __sigset_t), > >... > >I've include (for __uint32_t) and > >instead. timespec is declared through . > > Too bad. Do you have a better suggestion? > >> Just namespace pollution. > > > >We need MINSIGSTKSZ from 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 > but not in . > - PTHREAD_STACK_MIN must be defined as a number (if at all even if > XSI is no visible. I agree that is missing the PTHREAD_{DESTRUCTOR_ITERATIONS,KEYS_MAX,STACK_MIN,THREADS_MAX} macros. It's not an error for 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 ? > >> Just namespace pollution. > > > > 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 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