std::optional - unchecked deref security concern

[tiagomacarios]

With #878 - : Don't zero storage in default constructor wouldn't we have a security concern around the use of optional?

Take the following code as an example:

#include <optional>
#include <iostream>

int main()
{
    std::optional<int> i = std::nullopt;
    std::cout << *i << '\n';
    return *i;
}

Looking at the godbolt output for clang I get a random number on every execution. I am expecting the same behavior for msvc going forward. I understand that there are performance concerns as well and I am wondering if we could have a debug only check for optional (just like we do buffer overrun checks for vector).

What I have in mind is something similar to llvm::expected behavior. It is has a member variable that tracks if the object was ever checked. If during the lifetime of the object it's contents where never checked the program is ill formed.

I think this makes sense in two accounts:

• the security concern
• misuse of optional when a value could be enough

Downsides:

• ABI breaking - Could be protected under a #if (just like LLVM)
• Possible use confusion

If the above makes sense I can try to create a PR.

[CaseyCarter]

I am wondering if we could have a debug only check for optional (just like we do buffer overrun checks for vector).

We should have had precondition checks for operator* and operator-> in the first place. Mea culpa, std::optional was my first real task and I didn't have a feel yet for how to do asserts in the STL. How does #1362 look?

If during the lifetime of the object it's contents where never checked the program is ill formed.

This seems too niche to be generally useful. optional is not expected; the two are more similar to variant than to each other. There are as many use cases for optional that don't care if the optional is always inspected as there are use cases that do. Coupled with the ABI issues, this sounds less like a job for optional and more like a job for a type implemented in terms of optional.