This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It is necessary for correctness that destructors are run for objects which have
completed a constructor. It is not necessary for correctness to order static
destructors after the destructor for an object still being initialized, both
interpretations are reasonable.

It seems fairly clear to me that initialization for data(1) is not complete
until the principal constructor returns.

(In reply to lh_mouse from comment #0)
> The problem would be gone only if the GCC front-end registers the dtor after
> the delegated constructor returns.

But then if the delegating constructor throws you would run the destructor
twice e.g.

extern "C" int puts(const char*);

struct X {
  X() {
    puts("delegated constructor");
  }
  X(int) : X() {
    puts("delegating constructor");
    throw 1;
  }
  ~X(){
    puts("destructor");
  }
};

int main() {
  try {
    X x(1);
  } catch (...) {
  }
}

Until the delegating constructor returns normally you can't know if the
destructor needs to be registered.

> Is this a GCC bug?

I'm coming to the conclusion it isn't a bug, but is required for correctness.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]