public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Torvald Riegel <triegel@redhat.com>
To: Rich Felker <dalias@aerifal.cx>
Cc: GLIBC Devel <libc-alpha@sourceware.org>,
	       libc-ports <libc-ports@sourceware.org>
Subject: Re: [PATCH] Unify pthread_once (bug 15215)
Date: Fri, 10 May 2013 08:31:00 -0000	[thread overview]
Message-ID: <1368174657.7774.2130.camel@triegel.csb> (raw)
In-Reply-To: <20130509155613.GM20323@brightrain.aerifal.cx>

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?


Torvald

  reply	other threads:[~2013-05-10  8:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08 14:44 Torvald Riegel
2013-05-08 17:51 ` Rich Felker
2013-05-08 20:47   ` Torvald Riegel
2013-05-08 21:25     ` Rich Felker
2013-05-09  8:39       ` Torvald Riegel
2013-05-09 14:02         ` Rich Felker
2013-05-09 15:14           ` Torvald Riegel
2013-05-09 15:56             ` Rich Felker
2013-05-10  8:31               ` Torvald Riegel [this message]
2013-05-10 13:22                 ` Rich Felker
2013-05-23  4:15 ` Carlos O'Donell
2013-08-26 12:50   ` Ondřej Bílka
2013-08-26 16:45     ` Rich Felker
2013-08-26 18:41       ` Ondřej Bílka
2013-08-27  2:29         ` Rich Felker
2013-10-06  0:20   ` Torvald Riegel
2013-10-06 21:41     ` Torvald Riegel
2013-10-07 16:04     ` Joseph S. Myers
2013-10-07 21:53       ` Torvald Riegel
2014-03-31 11:44         ` Will Newton
2014-03-31 20:09           ` Torvald Riegel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1368174657.7774.2130.camel@triegel.csb \
    --to=triegel@redhat.com \
    --cc=dalias@aerifal.cx \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).