This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Principles for API sources


To summarize discussion so far:

I think we have general support for the given principles (including 
selectively accepting modern BSD APIs on the basis of widespread use, even 
where there are deficiencies in those APIs), though with disagreement on 
the quality of API review that takes place in the BSD and Linux kernel 
contexts.

There seems to be support for the binary floating-point APIs from TS 18661 
parts 1, 3 and 4, but only one person replied to 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html> (and it was 
suggested that there might be, hypothetically, concerns that no-one has 
actually said they have).  This is assuming any substantial implementation 
piece starts with a coherent design based on a good global understanding 
of glibc libm issues and of TS 18661, and that such a design then gets 
community consensus, rather than starting by hacking up whatever first 
comes to mind.  Views from more people on these APIs would be desirable.

There's support for TR 24731-2 (Dynamic Allocation Functions) APIs 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00230.html>.

Thread-safe timezone interfaces were mentioned in passing 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00238.html>, but there 
hasn't been a separate proposal for them.

Following <https://sourceware.org/ml/libc-alpha/2015-11/msg00233.html>, 
the current consensus seems to be against C11 Annex K functions unless 
they become widely used.  C11 threads have support as an API set; the 
other ISO C TR / TS / standard optional APIs I mentioned didn't receive 
discussion, but I wasn't making any explicit proposals regarding them 
anyway.

There is no consensus so far on what to do with Linux kernel syscalls that 
are *not* appropriate for the OS-independent GNU API.  Previously there 
were objections to putting them in libc.so.N; now there are objections to 
putting them in a separate libinux-syscalls.so.1.  So this still needs to 
be discussed further.

The more specific proposals I made regarding appropriateness of particular 
syscalls for the OS-independent GNU API in 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00373.html> still need to 
be discussed.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]