init_priority and initialization of POD types

Martin Sebor
Tue Aug 18 20:18:00 GMT 2015

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
> (
>      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.


More information about the Gcc-help mailing list