Re: Principles for API sources

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 10 Nov 2015, Zack Weinberg wrote:

> I am of the opinion that glibc should provide wrappers, in libc.so, for
> *all* system calls for each platform it can be used with (which I

Do you mean libc.so.N the shared library, as opposed to libc.so the linker 
script that may use AS_NEEDED to link in other shared libraries as well?

> believe is currently just Linux, Hurd, and NaCl?).  I'd only make an
> exception for system calls that *cannot* be used safely by an
> application without treading on glibc's own use of them.  In particular,
> the fact that a syscall is X-specific and shows no signs of being
> adopted anywhere else is *not* a disqualifier in my book; it just
> wouldn't be available on all supported platforms.

I don't object myself to such a principle, but don't see it as 
particularly likely to get consensus (at least two people seemed to be 
sustaining objections to adding new wrappers for Linux-specific 
interfaces, in previous discussion - see 
<https://sourceware.org/ml/libc-alpha/2014-10/msg00591.html> and 
<https://sourceware.org/ml/libc-alpha/2015-05/msg00557.html>).  So this 
proposal is deliberately more limited in the hopes that a narrow range of 
interfaces could get consensus for the OS-independent GNU API.

> > * The fact that an API already exists and is being used in free software 
> > (in a context where it isn't deprecated) should be considered a point in 
> > favour of inclusion of that API, that can counterbalance arguments about 
> > imperfections in the API design; the more widespread the usage is, the 
> > more important it is as an argument for inclusion.  Deficiencies in API 
> > design, or issues of consistency with other APIs in glibc, can still be 
> > relevant issues.  But whether they outweigh usage depends on how serious 
> > the deficiencies are, and how widespread the usage is.
> 
> I've seen people argue against strlcpy in particular because "we want to
> discourage people from using it".  It's my opinion that this has not
> worked, but it is still at least a tempting argument; I might make the
> same argument myself about Annex K, for instance.  What is your opinion
> of this argument?

I don't see it as relevant to a widely-used API, at least not unless it's 
as bad as gets (i.e. almost impossible to use safely).

-- 
Joseph S. Myers
joseph@codesourcery.com