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

[Rich Felker <dalias at libc dot org>]

On Mon, Dec 22, 2014 at 06:21:50PM -0800, Paul Eggert wrote:
> Rich Felker wrote:
> >I don't recall any such consensus,
> 
> Well, to be fair I didn't call it a consensus, only a "most favored
> suggestion".  I agree it didn't have consensus.
> 
> >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.
> 
> That goes only so far.  Suppose the spec for plain traditional
> strcpy were in Annex K, and glibc supplied a strcpy implementation
> that mostly worked, except it failed to copy the trailing null byte.
> I doubt whether users would be satisfied with the justification
> "well, this doesn't *conflict* with the spec, and it's *partial*
> support for the standard".  Similarly for a memset_s that fails to
> throw an exception if you invoke it with invalid arguments.

Annex K does not specify that it "throws an exception" (what would
that mean?) or aborts the program or anything. The default runtime
constraint handler is implementation-defined, and just returning an
error is one option. This is one reason why Annex K is basically
unusable: you can't rely on any particular behavior for what happens
on a runtime constraint violation unless you install your own handler,
but the handler is global (not even thread-local) so you can't even
safely install it on a temporary basis and switch it back.

This level of misdesign is at most barely-tolerable in legacy
interfaces that are being supported in continuance of a historical
practice, but it's utterly absurd to add new interfaces like this.

In any case I think you misinterpreted my concept of conflicting vs
not-incompatible. A strcpy that doesn't null-terminate would be
*conflicting* in my sense, because it never produces the specified
behavior unless the destination string is already zero-filled. On the
other hand, the proposed memcpy_s would never be observably different
from the spec in Annex K except in a program which attempted to set
the constraint handler, which would not even successfully compile/link
since this function is missing.

Rich