Re: High priority bug?

[Ross Smith <ross dot s at ihug dot co dot nz>]

Carlo Wood wrote:
> 
> I just did ran into a weird bug, not sure if you want to fix it
> in 3.0 however.  Its kinda hard to produce a short test case,
> so I'd like to first ask if this is considered a high priority
> bug before trying.
> 
> The problem is as follows:
> 
> In a shared library I am using the following definition:
> 
>   #include <limits>
>   int const failure = std::numeric_limits<int>::min();
> 
> And I assumed that `failure' was a _constant_ (and hence initialized
> at all times), but it turns out that instead it gets initialized as
> part of (or after?) __do_global_ctors_aux().  Even more, other global
> objects are initialized before this "constant" is initialized - making
> my program crash.

Not a bug.

Dynamically initialised objects (whether they're const or not isn't
relevant) may be initialised either at some point before the call to
main() or at some point before their first use in the same translation
unit. (See section 3.6.2 of the C++ standard.) No promises are made
about the order of initialisation between different translation units.

Zero-initialisation and initialisation from a constant expression are
static initialisation (which is guaranteed to happen before any part of
the program is executed); anything else is dynamic initialisation. Your
initialisation involves a function call, so it isn't static.

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green