This is the mail archive of the 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]

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

On Mon, Dec 22, 2014 at 2:46 PM, Rich Felker <> wrote:
> 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.

Incidentally, there are some places in glibc which, in order to match
the programmers' intent, probably need functionality like this today.

For example, see the memset calls at the end of:

The documented intent there is to clear data from the stack before
returning, but the compiler is free to remove them IIUC.

(As I said before, it doesn't make a big difference to me whether a
non-removable memset is called memset_s() or whether it's called
explicit_bzero() or whether it gets another name entirely.)


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