OvermindDL1 wrote:
[snip]
one (gcc related) bug-fix due to how this library implements something that is not well defined in the standard.
It is defined pretty clear (for me) in 3.8/6 of 14882:2003: _quote_ Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any lvalue which refers to the original object may be used but only in limited ways. Such an lvalue refers to allocated storage (3.7.3.2), and using the properties of the lvalue which do not depend on its value is well-defined. If an lvalue-to-rvalue conversion (4.1) is applied to such an lvalue, the program has undefined behavior; if the original object will be or was of a non-POD class type, the program has undefined behavior if: — the lvalue is used to access a non-static data member or call a non-static member function of the object, or — the lvalue is implicitly converted (4.10) to a reference to a base class type, or — the lvalue is used as the operand of a static_cast (5.2.9) (except when the conversion is ultimately to char& or unsigned char&), or — the lvalue is used as the operand of a dynamic_cast (5.2.7) or as the operand of typeid. _end_of_quote
[snip]