c++/9881: Incorrect address calculation for static class member

[Peter A. Buhr]

   > Finally, your suggestion is not even
   > a work-around, because the original problem occurred in separate compilation
   > units, so the notion of moving the constructor in this case does not apply.

   At which point you are out of luck in any case, since the standard does 
   not give any guarantee about the order of initialization in case there are 
   more than one translation units.

I think it does. All static variables in all translation units must be
initialized before any global constructors in any translation unit. The static
initialization is usually done by reading constants from the .data section or by
the linker/loader. So if I initialize a static variable in one translation
unit, it must be initialized before a constructor is run in any another
translation unit. I think you are referring to the order of evaluation of
global constructors across translation units, which is undefined.

   May other language lawyers decide this case, regards

Let me change the program slightly and see if this clarifies the situation.

   #include <iostream>
   
   using namespace::std;
   
   struct bar {
       double p;
   }; // bar
   
   struct module {
       static double *b;
       static double storage;
   };
   
   class foo {
     public:
       foo() {
   	// the output for both values should be the same
   	cout << &module::storage << " " << module::b << endl;
       }
   };
   
   foo f; // print output
   
   bar v;
   double *module::b = &(((bar *)(&v))->p); // LINE X
   //double *module::b = &(((bar *)(&module::storage))->p); // LINE Y
   double module::storage = 0.0;
   
   int main() {
   }

If you run this with gcc3.3, the output is:

@awk[5]% a.out
0x8049a50 0x8049a48

Now comment out LINE X, and uncomment LINE Y and run again getting output:

@awk[6]% a.out
0x8049a78 0

Zero (0) is not an acceptable address. BUT, the only different between these 2
lines is the chunk of storage for the object. Notice this has nothing to do
with the constructor. One case works and one doesn't. Is this not compelling?