If a global variable is initialized twice (statically, then dynamically), which initialization starts its lifetime?

Question

Inspired by this question.

We know that global variables with non-constexpr initializers undergo two different "initializations":

• First, the "static initialization", which zero-initializes them.
• Second, the "dynamic initialization", which uses the user-provided initializer.

Which of those initializations starts the variable lifetime? [basic.life] is being surprisingly unhelpful:

The lifetime of an object ... begins when: ... its initialization (if any) is complete

I see several options:

1. The last initialization starts the lifetime.
2. The first initialization starts the lifetime.
3. Each successive initialization destroys the existing object and creates a new one in its place.

(1) Would make the most sense, but it would make the static initialization of an object that will later be dynamically initialized mostly useless.

(2) Would have interesting effects. E.g. the static init order fiasco is suddenly not UB (by itself) anymore.

(3) Would be very weird.

Answer 1

Indeed, the standard is vague by not specifying how exactly the quoted rule "initialization (if any) is complete" applies to multiple stages of initialization, each of which being referred to as "initialization". And this leaves room for multiple interpretations.

This footnote (non-normative) implies that the lifetime begins only after dynamic initialisation is complete:

[basic.life]

Before the lifetime of an object has started but after the storage which the object will occupy has been allocated ²⁶ ...

²⁶ For example, before the dynamic initialization of an object with static storage duration ([basic.start.dynamic]).

Answer 2

As the other answer makes its argument solely on a non-normative footnote, I will offer a counter-argument based on non-normative note. Not that I have any belief in this interpretation over the other, but I think the standard is in non-normative conflict here, at best.

Note 2 of [basic.start.static]/3 gives an example of unspecified, not undefined, behavior where an implementor (adhering to [basic.start.static]/3) is permitted to perform initialization of a static/thread storage duration variable even if it is not required to be initialized during static initialization (could be during dynamic initialization). The key here being the note's example of why the value of obj1 is unspecified: namely that the value of the object which is used to initialize it may be "fully initialized" or "merely zero-initialized":

[Note 2: As a consequence, if the initialization of an object obj1 refers to an object obj2 potentially requiring dynamic initialization and defined later in the same translation unit, it is unspecified whether the value of obj2 used will be the value of the fully initialized obj2 (because obj2 was statically initialized) or will be the value of obj2 merely zero-initialized. For example,

inline double fd() { return 1.0; }
extern double d1;
double d2 = d1;     // unspecified:
                    // either statically initialized to 0.0 or
                    // dynamically initialized to 0.0 if d1 is
                    // dynamically initialized, or 1.0 otherwise
double d1 = fd();   // either initialized statically or dynamically to 1.0

— end note]

Particularly the comment from the example code snippet:

[d2] either statically initialized to 0.0 or dynamically initialized to 0.0 if d1 is dynamically initialized, or 1.0 otherwise.

Implying that the "otherwise" case, namely where d1 is (dynamically) initialized from the "merely zero-initialized" d2 is not undefined.