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
