QArrayData: fix potential UB in QBasicAtomic initializationHEADdev

Until C++17 (inclusive), a default-constructed std::atomic object can,
officially, only be initialized with a call to std::atomic_init, for
which QBasicAtomic doesn't have API. It is even unclear whether
zero-initialization of static and thread-local objects will cause the
object to be initialized.

Seeing as we can't rely on malloc's zero-initialization to properly
initialize std::atomic objects (and therefore QBasicAtomic ones), and
because it's the right thing to do, from a [basic.life] POV, anyway,
port to placement new instead.

The realloc() feels fishy, seeing as it reallocs a struct that
contains an atomic variable (which we don't mark as Q_RELOCATABLE_TYPE
even for our own types), but assume that part it ok, and in-place
construct only if realloc() was passed nullptr (so is equivalen to
malloc()). A final solution for this can probably only be implemented
when we can depend on C++20's atomic_ref, which decouples the
underlying object from the atomic operations performed on it.

Rename the ref_ member to m_ref to catch any uses of the variable,
incl. since removed ones in older branches.

Amends 812a611dc05e5facd036856625ccb9274fdcb117 (which ported from
QtPrivate::RefCount to QBasicAtomicInt; I didn't check whether
QtPrivate::RefCount had a similar problem, because that commit is
already much older than what I can pick back to at this point).

Task-number: QTBUG-137465
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: I188e05d09e20e0820af7cf1cbb651afa860bb9d6
Reviewed-by: Thiago Macieira <[email protected]>

0 files changed, 0 insertions, 0 deletions