This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: Principles for API sources
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 11 Nov 2015 15:32:12 -0500
- Subject: Fwd: 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> <alpine dot DEB dot 2 dot 10 dot 1511111813230 dot 11360 at digraph dot polyomino dot org dot uk> <CAKCAbMg1r2rUXmFXZ-_8CozVGBqA5KBNEwYvNm4t8Y=JPCFNzw at mail dot gmail dot com>
On Wed, Nov 11, 2015 at 1:21 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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?
Primarily I mean the linker script (or, more accurately yet, I mean
"you shouldn't have to put something extra on your link line") but I'm
more or less in agreement with Rich that a separate actual shared
library seems likely to cause more problems than it solves.
> 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.
I can support it as a starting point, anyway. (And there aren't any
syscalls that I'm particularly missing - well, there are, but they
don't exist in the *kernel* yet, so.)
>> 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).
Seems reasonable.
zw