From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5998 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: C threads, v. 6.2 Date: Sat, 30 Aug 2014 21:31:11 -0400 Message-ID: <20140831013111.GA12784@brightrain.aerifal.cx> References: <20140828215641.GD12888@brightrain.aerifal.cx> <1409268337.4476.151.camel@eris.loria.fr> <20140828233809.GE12888@brightrain.aerifal.cx> <1409298999.4476.163.camel@eris.loria.fr> <1409299363.4476.164.camel@eris.loria.fr> <20140829155744.GH12888@brightrain.aerifal.cx> <1409338871.4476.206.camel@eris.loria.fr> <20140830053036.GJ12888@brightrain.aerifal.cx> <1409384616.4476.231.camel@eris.loria.fr> <20140831003034.GN12888@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409448691 15571 80.91.229.3 (31 Aug 2014 01:31:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 01:31:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6005-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 31 03:31:24 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XNtzH-0001f6-Us for gllmg-musl@plane.gmane.org; Sun, 31 Aug 2014 03:31:24 +0200 Original-Received: (qmail 15919 invoked by uid 550); 31 Aug 2014 01:31:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15908 invoked from network); 31 Aug 2014 01:31:23 -0000 Content-Disposition: inline In-Reply-To: <20140831003034.GN12888@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5998 Archived-At: On Sat, Aug 30, 2014 at 08:30:34PM -0400, Rich Felker wrote: > > For the C thread TU, what would be the mechanics for them to call one > > of the (aliased) pthread functions? > > With my alternate solution just described, simply including the normal > pthread header and casting the pointer when making the call would be > fully legal. > > With the approach we previously discussed, where we have to ensure > that no TU that accesses the contents of a mutex or cv structure can > see both the C11 and POSIX versions, The C11 TUs would have to contain > prototypes for the aliased POSIX functions like: > > int __pthread_mutex_lock(mtx_t *); > > Note that this is a perfectly correct prototype because mtx_t is just > this TU's typedef name for the tagless "struct { union { ... } __u; }" > that it's using, which is "the same type" as pthread_mutex_lock.c's > pthread_mutex_t. Actually, unless the C11 functions actually access the mutex object, their implementation files don't need to avoid having both types visible. Only the TUs that dereference the object (i.e. the pthread ones) need to ensure that only one version of the type is visible. Rich