init_priority and initialization of POD types

init_priority and initialization of POD types

[Jeffrey Walton]

I'm tracking down some Valgrind findings. I believe I am seeing the following:

    // a.cpp
    bool g_flag = false;

    // b.cpp
    SomeObject g_object1 __attribute__ ((init_priority(150)));

    // c.cpp
    // Uses global flag from a.cpp, and SomeObject from b.cpp
    SomeOtherObject g_object2;

When I run the program under Valgrind, I'm catching an uninitialized
finding related to the global flag from a.cpp when g_object2 is used.

According to the man page on init_priority
(https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html):

    In Standard C++, objects defined at namespace scope are guaranteed
    to be initialized in an order in strict accordance with that of their
    definitions in a given translation unit. No guarantee is made for
    initializations across translation units. However, GNU C++ allows users
    to control the order of initialization of objects defined at namespace scope
    with the init_priority attribute by specifying a relative
priority, a constant
    integral expression currently bounded between 101 and 65535 inclusive.
    Lower numbers indicate a higher priority.

I assumed the object initialization came after POD initialization in a
translation unit, but it appears I am wrong. In fact, the man page
does not discuss the scenario.

What is the relationship among C++ objects with an init_priority
attribute and other POD types across translation units?

Thanks in advance.

Jeff

Re: init_priority and initialization of POD types

[Martin Sebor]

On 08/12/2015 12:19 PM, Jeffrey Walton wrote:
> I'm tracking down some Valgrind findings. I believe I am seeing the following:
>
>      // a.cpp
>      bool g_flag = false;
>
>      // b.cpp
>      SomeObject g_object1 __attribute__ ((init_priority(150)));
>
>      // c.cpp
>      // Uses global flag from a.cpp, and SomeObject from b.cpp
>      SomeOtherObject g_object2;
>
> When I run the program under Valgrind, I'm catching an uninitialized
> finding related to the global flag from a.cpp when g_object2 is used.
>
> According to the man page on init_priority
> (https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html):
>
>      In Standard C++, objects defined at namespace scope are guaranteed
>      to be initialized in an order in strict accordance with that of their
>      definitions in a given translation unit. No guarantee is made for
>      initializations across translation units. However, GNU C++ allows users
>      to control the order of initialization of objects defined at namespace scope
>      with the init_priority attribute by specifying a relative
> priority, a constant
>      integral expression currently bounded between 101 and 65535 inclusive.
>      Lower numbers indicate a higher priority.
>
> I assumed the object initialization came after POD initialization in a
> translation unit, but it appears I am wrong. In fact, the man page
> does not discuss the scenario.
>
> What is the relationship among C++ objects with an init_priority
> attribute and other POD types across translation units?

POD objects with static storage duration with constant initializers
are initialized statically, at program load time, before dynamic
initialization starts. They're not subject to init_priority which
applies to dynamically initialized objects (i.e., whose ctors run
at program startup). I can't imagine under what circumstances
Valgrind would complain that a statically initialized POD object
is uninitialized.

Martin