// If the string is short enough, we store the string itself
// instead of a pointer to the string.
@ -7361,7 +7399,7 @@ But heed the warning: [Avoid "naked" `union`s](#Ru-naked)
char* string_ptr;
char string_buffer[buffer_size];
};
const size_t size;
};
@ -11659,16 +11697,16 @@ this can be a security risk.
##### Enforcement
Some is possible, do at least something.
There are commercial and open-source tools that try to address this problem, but static tools often have many false positives and run-time tools often have a significant cost.
We hope for better tools.
When possible, rely on tooling enforcement, but be aware that any tooling
solution has costs and blind spots. Defense in depth (multiple tools, multiple
approaches) is particularly valuable here.
Help the tools:
There are other ways you can mitigate the chance of data races:
* less global data
* fewer`static` variables
* more use of stack memory (and don't pass pointers around too much)
* more immutable data (literals, `constexpr`, and `const`)
* Avoid global data
* Avoid`static` variables
* More use of value types on the stack (and don't pass pointers around too much)
* More use of immutable data (literals, `constexpr`, and `const`)
### <aname="Rconc-data"></a>CP.3: Minimize explicit sharing of writable data
@ -12671,7 +12709,7 @@ Example with thread-safe static local variables of C++11.
static My_class my_object; // Constructor called only once
// ...
}
class My_class
{
public:
@ -12694,7 +12732,7 @@ Double-checked locking is easy to mess up. If you really need to write your own
##### Example, bad
Even if the following example works correctly on most hardware platforms, it is not guaranteed to work by the C++ standard. The x_init.load(memory_order_relaxed) call may see a value from outside of the lock guard.
Even if the following example works correctly on most hardware platforms, it is not guaranteed to work by the C++ standard. The x_init.load(memory_order_relaxed) call may see a value from outside of the lock guard.
atomic<bool> x_init;
@ -12711,12 +12749,12 @@ Even if the following example works correctly on most hardware platforms, it is
One of the conventional patterns is below.
std::atomic<int> state;
// If state == SOME_ACTION_NEEDED maybe an action is needed, maybe not, we need to
// check again in a lock. However, if state != SOME_ACTION_NEEDED, then we can be
// sure that an action is not needed. This is the basic assumption of double-checked