This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TR 24731-2 (dynamic allocation functions) as API source
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Roland McGrath <roland at hack dot frob dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 11 Nov 2015 23:35:33 +0000
- Subject: Re: TR 24731-2 (dynamic allocation functions) as API source
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511111823550 dot 11360 at digraph dot polyomino dot org dot uk> <20151111202440 dot 08D9A2C3AA0 at topped-with-meat dot com> <5643CE91 dot 5050208 at cs dot ucla dot edu>
On Wed, 11 Nov 2015, Paul Eggert wrote:
> Roland McGrath wrote:
> > I agree this is a reasonable set of interfaces for libc.
>
> I also don't object to these. Though it must be asked: are applications using
> these functions? Have application developers expressed a need for them? I
> expect the answer is "no", and that they're low priority.
In terms of demand from users, I certainly expect the highest priority new
interfaces taken from external sources are strlcpy, strlcat,
explicit_bzero, gettid / pthread_gettid_np, futex / futex_*, and most of
the past few years' Linux kernel syscalls (in no particular order). But
several of those are also more controversial for one reason or another.
(There was at least one instance of demand for TS 18661-1 roundeven:
<https://sourceware.org/ml/libc-help/2015-02/msg00005.html>
<https://sourceware.org/ml/libc-help/2015-03/msg00002.html>.)
--
Joseph S. Myers
joseph@codesourcery.com