Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.

[Rich Felker <dalias at libc dot org>]

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