From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5999 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 22:44:29 -0400 Message-ID: <20140831024429.GA13259@brightrain.aerifal.cx> References: <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> <20140831013111.GA12784@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 1409453089 2672 80.91.229.3 (31 Aug 2014 02:44:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 02:44:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6006-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 31 04:44:42 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 1XNv8E-0007oh-Bu for gllmg-musl@plane.gmane.org; Sun, 31 Aug 2014 04:44:42 +0200 Original-Received: (qmail 19855 invoked by uid 550); 31 Aug 2014 02:44:41 -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 19847 invoked from network); 31 Aug 2014 02:44:41 -0000 Content-Disposition: inline In-Reply-To: <20140831013111.GA12784@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:5999 Archived-At: On Sat, Aug 30, 2014 at 09:31:11PM -0400, Rich Felker wrote: > 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. The more I think about it, the more I think the visibility of the other type is utterly irrelevant. 6.5p7: "An object shall have its stored value accessed only by an lvalue expression that has one of the following types: a type compatible with the effective type of the object," 6.2.7p1: "Moreover, two structure, union, or enumerated types declared in separate translation units are compatible if their tags and members satisfy the following requirements: If one is declared with a tag, the other shall be declared with the same tag. If both are completed anywhere within their respective translation units, then the following additional requirements apply: there shall be a one-to-one correspondence between their members such that each pair of corresponding members are declared with compatible types; if one member of the pair is declared with an alignment specifier, the other is declared with an equivalent alignment specifier; and if one member of the pair is declared with a name, the other is declared with the same name. For two structures, corresponding members shall be declared in the same order. For two structures or unions, corresponding bit-fields shall have the same widths." As I read this, structure types declared in separate translation units, where neither has a tag and both have identical bodies, are compatible types, and thus allowed to alias. This means: 1. The pthread_mutex_t in pthread_mutex_*.c can alias the pthread_mutex_t in application TUs. 2. The pthread_mutex_t in pthread_mutex_*.c can alias the mtx_t in application TUs. 3. The mtx_t in mtx_*.c can alias the pthread_mutex_t in application TUs. 4. The mtx_t in mtx_*.c can alias the mtx_t in application TUs. The only aliasing that's not permitted is for the pthread_mutex_t and mtx_t in the _same_ _TU_ to alias each other. Is there any error in my above interpretation? Rich