This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 17 Jun 2013 20:49:31 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B65DE4 dot 4010107 at redhat dot com> <20130610231903 dot D9C602C09B at topped-with-meat dot com> <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com>
On Mon, 2013-06-17 at 12:44 -0400, Carlos O'Donell wrote:
> On 06/14/2013 06:44 PM, Roland McGrath wrote:
> >> I will assume that you would not be opposed to a configure
> >> switch that turns elision on or off with the default being
> >> elision off, but no questionable env vars to tune behaviour.
> >
> > Probably not, if the code enabled by the configure switch does not
> > diverge from the API and ABI guarantees we already make and does not
> > include anything generally ugly that we wouldn't want in the tree at all.
>
> Agreed. I guess I just wanted to clarify that the major sticking point
> right now is the env var usage, and without that then it's a matter of
> Torvald and I making sure the code does what it says and meets our
> usual guidelines.
The way I read Roland's comment is that independently of whether things
are controlled via a configure switch instead of an env var, they should
not diverge from the API or ABI guarantees (and this includes the POSIX
guarantees such as the relock case requirements for
PTHREAD_MUTEX_NORMAL). Roland, is that correct?