This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: Principles for API sources


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]