On Fri, Apr 24, 2020 at 5:13 PM JF Bastien via SG12 <sg12@lists.isocpp.org> wrote:
Hello SG12/UB folks,

I'd like to start a discussion about p1315 secure_clear. Please see the paper's history on github.

Here's what I'd want SG12's help on: assume that there's a need for some sort of "secure clearing of memory", how do we fit this into the abstract machine? What behavior do we specify, what do we leave open, while meeting the stated security goals?

Asking for clarification:

int i;  // i is live and uninitialized
int i = 2;
secure_clear(&i, sizeof(i));
// is i still a live int, and if so, is it considered uninitialized?

From both an SG12 and an LEWG point of view, it scares me to have a mechanism to turn an initialized int into an uninitialized int.

Sidebar:  It looks like C++20 already added such a mechanism :-(. I didn't realize that the behavior for calling a pseudo-destructor had changed for C++20 [diff.cpp17.basic], as that has implications for library and I don't remember the change going through both SG12 and LEWG (if it did, please disregard).

In C++17 and prior, the following code had no preconditions):

std::vector<int> Copy(std::vector<int> const& v)
{ return v; }

Now it does have an undocumented precondition, which makes it a breaking change.
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com>  +1-847-691-1404