From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30237 invoked by alias); 10 May 2013 13:22:13 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 30218 invoked by uid 89); 10 May 2013 13:22:12 -0000 X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC2,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 10 May 2013 13:22:11 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1UanGw-00064g-00; Fri, 10 May 2013 13:22:06 +0000 Date: Fri, 10 May 2013 13:22:00 -0000 To: Torvald Riegel Cc: GLIBC Devel , libc-ports Subject: Re: [PATCH] Unify pthread_once (bug 15215) Message-ID: <20130510132206.GP20323@brightrain.aerifal.cx> References: <1368024237.7774.794.camel@triegel.csb> <20130508175132.GB20323@brightrain.aerifal.cx> <1368046046.7774.1441.camel@triegel.csb> <20130508212502.GF20323@brightrain.aerifal.cx> <1368088765.7774.1571.camel@triegel.csb> <20130509140245.GI20323@brightrain.aerifal.cx> <1368112468.7774.2082.camel@triegel.csb> <20130509155613.GM20323@brightrain.aerifal.cx> <1368174657.7774.2130.camel@triegel.csb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1368174657.7774.2130.camel@triegel.csb> User-Agent: Mutt/1.5.21 (2010-09-15) From: Rich Felker X-SW-Source: 2013-05/txt/msg00048.txt.bz2 On Fri, May 10, 2013 at 10:30:57AM +0200, Torvald Riegel wrote: > On Thu, 2013-05-09 at 11:56 -0400, Rich Felker wrote: > > On Thu, May 09, 2013 at 05:14:28PM +0200, Torvald Riegel wrote: > > > > > I agree that the absence of a proper memory model makes reasoning about > > > > > some of this hard. I guess it would be best if POSIX would just endorse > > > > > C11's memory model, and specify the intended semantics in relation to > > > > > this model where needed. > > > > > > > > Agreed, and I suspect this is what they'll do. I can raise the issue, > > > > but perhaps you'd be better at expressing it. Let me know if you'd > > > > rather I do it. > > > > > > I have no idea how the POSIX folks would feel about this. After all, it > > > would create quite a dependency for POSIX. With that in mind, trying to > > > resolve this isn't very high on my todo list. If people would think > > > that this would be beneficial for how we can deal with POSIX > > > requirements, or for our users to understand the POSIX requirements > > > better, I can definitely try to follow up on this. If you want to go > > > ahead and start discussing with them, please do so (please CC me on the > > > tracker bug). > > > > POSIX is aligned with ISO C, and since the current version of ISO C is > > now the 2011 version, Issue 8 should be aligned to the 2011 version of > > the C standard. I don't think the issue is whether it happens, but > > making sure that the relevant text gets updated so that there's no > > ambiguity as to whether it's compatible with the new C standard and > > not placing unwanted additional implementation constraints like it may > > be doing now. > > So, if it is aligned, would POSIX be willing to base their definitions > on the C11 memory model? Or would they want to keep their sometimes > rather vague requirements and just make sure that there are no obvious > inconsistencies or gaps? My guess is that they would adopt the C11 model. Rich