Re: Principles for API sources

[Zack Weinberg <zackw at panix dot com>]

On 11/06/2015 09:07 AM, Joseph Myers wrote:
> Various recent proposals for new APIs taken from existing sources of APIs 
> seem to have got stuck for similar reasons.  This includes Linux kernel 
> syscall wrappers as well as explicit_bzero and strlcpy.  I'd like to 
> propose some general principles for such APIs in the hopes of unsticking 
> those discussions - if we can get consensus on principles (consensus does 
> not mean unanimity; consensus does not mean waiting indefinitely for 
> people who might want to contribute to the discussion at some 
> indeterminate point in the future) then we don't need to redebate the 
> principles for each proposed API, just consider how they apply to that 
> API.

I generally like the sound of this (and not just because it might
unstick explicit_bzero ;-) but I have a couple notes ...

> * Specifically, I think the following should be considered appropriate 
> sources for APIs to be added to the OS-independent GNU API in glibc, where 
> the APIs in question are the general sort of functionality traditionally 
> included in libc and associated libraries on Unix-like systems: Linux 
> kernel syscalls, where the functionality would plausibly be meaningful 
> under other kernels; modern BSD systems; other Unix-like operating 
> systems.  This is in order of preference: APIs from Linux syscalls have a 
> stronger expectation of appropriateness than those from modern BSD 
> systems, which have a stronger expectation of appropriateness than those 
> from other Unix-like operating systems.

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
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.

An argument that a syscall is poorly-designed and/or likely to get
superseded by a newer shinier idea in the near future is *more*
persuasive to me, but still not terribly persuasive weighed against the
principle that it's the C library's job to provide the syscall wrappers.
 All of them.

> * 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?

zw