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

["Peter A. Buhr" <pabuhr@plg2.math.uwaterloo.ca>]

The following reply was made to PR c++/9881; it has been noted by GNATS.

From: "Peter A. Buhr" <pabuhr@plg2.math.uwaterloo.ca>
To: bangerth@ticam.utexas.edu
Cc: asharji@uwaterloo.ca, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/9881: Incorrect address calculation for static class member
Date: Thu, 27 Feb 2003 17:51:18 -0500 (EST)

    > 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?