This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for API sources
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 11 Nov 2015 18:21:05 +0000
- Subject: Re: Principles for API sources
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511061326480 dot 10753 at digraph dot polyomino dot org dot uk> <5642A593 dot 8020206 at panix 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