'Ensures' example regarding security bug is misleading about cppcoreguidelines HOT 8 OPEN

In principle, a conforming compiler should not eliminate the Ensures that depends on the memset, then also eliminate the memset. However, "as-if" would allow eliding them all by treating them as dead writes.

It seems like we need to say something about Ensures being treated as I/O as part of the side effects of the program. Saying that would require (tiny) language support.

Suggestion: What if in SS-assertions, under the definition of Ensures, we added this:

Every access of a named object mentioned in an argument to Ensures shall be treated as a volatile access.

from cppcoreguidelines.

Editors discussed 8 Dec 2015 and on 14 Dec 2015.

from cppcoreguidelines.

We intend to change the example to something else, and address this particular security example as part of a new security profile (likely with a secure buffer type or wrapper).

from cppcoreguidelines.

Andrew, please add an "enhancement" label about security. (Done)

from cppcoreguidelines.

Notes: There are a few issues entangled here. Contracts today are macro-based. But when we have contracts as a language feature, compilers are prohibited from propagating any information into or out of contracts that will introduce undefined behavior in the contract.

We need to add a sentence that refers to Ensures and notes that while current compilers may have trouble with this we can at least express the intent.

from cppcoreguidelines.

compilers are prohibited from propagating any information into or out of contracts that will introduce undefined behavior in the contract

I don't understand what this is supposed to mean. The problem is not that there is undefined behavior in the contract check. The problem is the as-if rule: there is no way for a program to read the original contents of the buffer after the memset EXCEPT if it exhibits undefined behavior in some DIFFERENT location (e.g. buffer overflow/reading uninitialized stack variables).

If contracts really are expected to disallow optimizations based on the as-if rule (e.g. via treating the operands as volatile as suggested by Herb) I'm expecting a significant/unacceptable slowdown of c++ programs in the future.

from cppcoreguidelines.

Revisited this issue today. We'd like to continue delaying action on it whilst the Committee discusses Contracts.

from cppcoreguidelines.

Suggest:

1. preface this issue title with "I.7 " for benefit of new readers
2. improve the // better comment in I.7's second example, quoted by @comex in OP. This comment could summarize some of the discussion on this issue thread. Something like:
   // better, b/c expresses intent - but even better solution will come with Contracts

from cppcoreguidelines.