This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 threads ABI questions - enum values
- From: Rich Felker <dalias at libc dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 2 Oct 2014 18:29:58 -0400
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <20140727203825 dot GA13146 at brightrain dot aerifal dot cx> <alpine dot LNX dot 2 dot 00 dot 1408181622440 dot 743 at monopod dot intra dot ispras dot ru> <20140818192714 dot GS12888 at brightrain dot aerifal dot cx> <20141001211308 dot 88F742C397E at topped-with-meat dot com> <20141001211606 dot GN23797 at brightrain dot aerifal dot cx> <20141001213022 dot 798942C3AAD at topped-with-meat dot com> <20141002001720 dot GO23797 at brightrain dot aerifal dot cx> <20141002214229 dot 734B62C3A2F at topped-with-meat dot com>
On Thu, Oct 02, 2014 at 02:42:29PM -0700, Roland McGrath wrote:
> > For mutex types, I suppose there's some risk of "sloppily" passing a
> > literal 0 without meaning mtx_plain, but I think it's a small issue
> > and I hope we can agree that keeping a common set of constants for ABI
> > purposes is of more value.
>
> We're not going to set a precedent of clearing ABI choices with another
> implementation or letting another implementation's past choices dictate
> to us. Of course, harmonization is a good thing. But you need to be
That's understandable.
> realistic about the relative positions of musl and glibc in terms of
> installed base and de facto standards for GNU/Linux systems.
Yes, that's why I've aimed to follow ABI rather than setting it. But
there are a few places where glibc is behind the current standards in
ways that require ABI decisions (O_SEARCH, O_EXEC, NI_NUMERICSCOPE, and
O_TTY_INIT are the examples that come to mind immediately) where it
would be really nice to have either some direction from glibc, or at
least a tenative assignment of values planned.
> This is a brand new feature and musl has few users even for features that
> have existed for any length of time. Are you really saying you cannot
> change your recent ABI choices for new things that nobody is actually using?
If there were a strong reason at this point, where it's not being used
and not present in any release, we probably could. But it's rather
frowned upon and seen as unprofessional by much of our user community.
Rich