[Bug c++/42063] New: g++ violate [class.dtor] when explicit destructor call

[Bug c++/42063] New: g++ violate [class.dtor] when explicit destructor call

[pi3orama at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

This bug is related to the example in [class.dtor]/12 of standard N2960.

according to the example, in the following program:

#include <iostream>
struct B {
        virtual ~B() { std::cout << "~B" << std::endl; }
};

struct D : B {
        ~D ()  { std::cout << "~D" << std::endl; }
};

typedef B B_alias;
int main()
{
        D D_object;
        B* B_ptr = &D_object;
        std::cout << "begin" << std::endl;
        D_object.B::~B();
        B_ptr->~B();
        std::cout << "end" << std::endl;
        return 0;
}

D_object .B::~B () should call B¡¯s destructor, and
B_ptr ->~B () should call D's destructor.

However the actual result is

begin
~B
~B
end
...

the strange thing is when D_object.B::~B() be removed, or be swapped between
B_ptr->~B(), everything is OK.

Another problem: according to the spec, 'Once a destructor is invoked for an
object, the object no longer exists'. However, the following code shows that
g++ doesn't respect it:

#include <iostream>
struct C {
        ~C() { std::cout << "XXX" << std::endl; }
};
int main()
{
        C * c = new C();
        c->C::~C();
        delete c;
        return 0;
}

the program ends normally. Shouldn't it generate a double free fault?


-- 
           Summary: g++ violate [class.dtor] when explicit destructor call
           Product: gcc
           Version: 4.3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pi3orama at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063

[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-11-16 13:16 -------
I don't have the time to analyze this, but I note that a binary built with ICC
behaves exactly the same way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063

[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-11-16 13:59 -------
The confusion stems from the way, slightly confusing, in which the example in
the standard is written, which, if considered an actually runnable snippet,
invokes undefined behavior, because destroys the base of D_object two times. If
you change it to something like:

  D D_object, D_object2;
  B* B_ptr = &D_object2;
  std::cout << "begin" << std::endl;
  D_object.B::~B();
  B_ptr->~B();
  std::cout << "end" << std::endl;

Then the example still explain the important role of virtual destructors - that
is, B_ptr->~B() invokes ~D, *not* ~B (after that, ~B is implicitly invoked, as
normally happens in inheritance hierarchies) - but no undefined behavior is
involved.

Talking about undefined behavior, after "Once a destructor is invoked for an
object, the object no longer exists" the (draft C++0x) standard continues ";
the behavior is undefined if the destructor is invoked for an object whose
lifetime has ended": as any undefined behavior, anything can happen, depending
on the actual size of the class being destructet, depending on the diagnostics
enabled in the underlying memory allocation functions, etc.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063

[Bug c++/42063] g++ violate [class.dtor] when explicit destructor call

[redi at gcc dot gnu dot org]

------- Comment #3 from redi at gcc dot gnu dot org  2009-11-17 10:01 -------
Also, please note that n2960 is not a standard, it's only a draft, and it's not
even the latest draft.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063