Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 May 2023 16:57:21 -0400
From: Rich Felker <>
To: Jₑₙₛ Gustedt <>
Cc: Joakim Sindholt <>,
Subject: Re: [C23 string conversion 1/3] C23: add the new
 memset_explicit function

On Fri, May 26, 2023 at 10:35:52PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
> on Fri, 26 May 2023 16:16:03 -0400 you (Rich Felker <>)
> wrote:
> > We had all of these discussions back when explicit_bzero was added,
> > and it was done the way it was done because it's portable (within the
> > framework of what musl already requires) and non-arch-specific, has
> > zero overhead, avoids any code duplication or bad performance
> > open-coding another memset variant,
> My impression is that such information is quite difficult to find, but
> maybe I didn't search enough. Sometimes code comments would help ;-)

It was discussed in the "thoughts on reallocarray, explicit_bzero?"
thread in 2014, starting here:

> Bad performance really isn't a valid argument in this case. This is
> not supposed to be efficient. Any user that uses this has to know that
> they are trading it for something.

I'm not sure whether performance here is a good criterion or not, but
making it ~gratuitously~ slow with an extra implementation of memcpy
open-coded here does not make sense.

> > and avoids taking part in any security theater (pretending we can
> > clear things we can't).
> It is not about taking part. For me it is just about offering to our
> users the best service for this tricky question that we may, and not
> less.

Do you have something in mind about how the explcit_bzero
implementation we have doesn't do that?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.