Re: Principles for API sources

[Rich Felker <dalias at libc dot org>]

On Tue, Nov 10, 2015 at 09:18:59PM -0500, Zack Weinberg wrote:
> > * 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.

I tend to agree with this. I can see where we might have minor
disagreements about what constitutes "cannot be used safely by an
application without treading..." or "poorly-designed", but things like
that can always be discussed and interpreted on an individual basis
once we have a good general principle to follow.

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

My opinion of the difference is that people working on software for
platforms that use glibc want to use strl* and are already using them
(dropping in their own implementation when it's missing). On the other
hand nobody is using Annex K. If that changes and 3 years from now
Annex K is implemented on other major POSIX-like systems and/or
there's all sorts of code using Annex K via drop-in-replacements (not
possible for the full thing, but for large portions), then I think the
arguments that apply for strl* now would apply to Annex K.

Rich