This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 22 Dec 2014 14:46:46 -0500
- Subject: Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.
- Authentication-results: sourceware.org; auth=none
- References: <CAKDKvuzWYf3GcXYs4ED8XLyy58nzmvxRV84xwsKKZjPpVSFQug at mail dot gmail dot com> <CAKDKvuxUCWsoavp4aFo_bmh1D_YrrJQ+ctULLkhXt9nXtMbUMw at mail dot gmail dot com> <5497207D dot 7040008 at cs dot ucla dot edu>
On Sun, Dec 21, 2014 at 11:33:17AM -0800, Paul Eggert wrote:
> Nick Mathewson wrote:
>
> >if I'm reading the consensus right, people think
> >that the implementation is correct, and the functionality is
> >standards-conformant and probably better than nothing.
>
> I don't see that consensus. As I recall, the proposed functionality
> doesn't conform to C11 Annex K, and it's not clear (to me at least)
> that the patch is better than nothing.
It doesn't conflict with Annex K in any way. IMO there's a huge
difference in adding an interface that conflicts with he requriements
of Annex K (even if glibc doesn't want to support Annex K now or for
the forseeable future), and adding one which simply does not support
all the 'features' specified in Annex K but matches the semantics for
the features it does support.
> As I understand it the most favored suggestion in the past has been
> that Annex K functionality should be packaged into a separate
> library libc_s; see, for example
> <https://sourceware.org/ml/libc-alpha/2014-08/msg00141.html>. You
> might want to look into efforts along those lines, e.g., slibc
> <https://code.google.com/p/slibc/>.
I don't recall any such consensus, and I don't see any value of
putting something in a separate library file unless it can actually be
an independent package from libc, which Annex K can't (due to
requirements in the headers and interactions with stdio internals,
etc.). I hope we can agree we've come to regret this when it's
happened before, e.g. clock_gettime being in librt and locking
functions being in libpthread, and other such messes which have led to
invalid hacks in applications and third-party libraries (like weak
references to pthread symbols and busybox's use of syscall() to get
clock_gettime).
So far I'm not aware of any consensus that glibc should aim to
support Annex K at all, and I hope it stays that way.
Rich