<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 7:15 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><p dir="ltr"><br>
On 4 Oct 2013 02:49, "emmanuel.attia" <<a href="mailto:emmanuel.attia@philips.com" target="_blank">emmanuel.attia@philips.com</a>> wrote:<br>
><br>
> > This has undefined behavior. You're calling a virtual function on an object<br>
> whose lifetime has ended (the destructor has already been called).<br>
><br>
> my_destroy_interface has no destructor so the vtable is not cleared until<br>
> the memory is released (since nothing alters it before i get in the operator<br>
> delete overload).<br>
><br>
> Referring to the standards (i'm not sure its the right pdf):<br>
> "The lifetime of an object of type T ends when:<br>
> — if T is a class type with a non-trivial destructor (12.4), the destructor<br>
> call starts, or<br>
> — the storage which the object occupies is reused or released."<br>
> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf</a><br>
><br>
> And that make totally sense since if i add a  (non-virtual) destructor it<br>
> still flies, unless the destructor is non trivial (in that case i get as<br>
> expected a pure virtual function call).</p>
</div><p dir="ltr">This is sort of beside the point, since you had undefined behaviour earlier:</p><div class="im">
<p dir="ltr">> > This has undefined behavior (you're using 'delete', the static and dynamic<br>
> > types don't match, and your base class does not have a virtual<br>
> > destructor).<br>
><br>
> That's the point, i call the overload "my_destroy_interface::operator<br>
> delete" and not the global delete operator. Since my_destroy_interface has<br>
> no (non trivial) destructor this is the only thing happening when calling<br>
> delete on a pointer to my_destroy_interface.</p>
</div><p dir="ltr">You can't reason like that about undefined behaviour. You deleted an object thorough the wrong static type and the dtor is not virtual, so you've already lost.</p><div class=""><div class="h5">

<p dir="ltr">> > Nope. See above. Or try giving my_destroy_interface a user-declared<br>
> > (non-virtual) destructor, and watch as it either gets called twice or your<br>
> > program starts to die due to a pure virtual function call (depending on<br>
> > implementation details).<br>
><br>
> Giving to my_destructor_interface a virtual destructor would make it called<br>
> twice as you said, thats why it's not there in this construct (and it makes<br>
> sense since its an interface).<br>
><br>
><br>
><br>
><br>
> --<br>
> View this message in context: <a href="http://clang-developers.42468.n3.nabble.com/is-delete-on-abstract-with-non-virtal-ever-safe-tp4025653p4034880.html" target="_blank">http://clang-developers.42468.n3.nabble.com/is-delete-on-abstract-with-non-virtal-ever-safe-tp4025653p4034880.html</a><br>


> Sent from the Clang Developers mailing list archive at Nabble.com.<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div><div class="gmail_extra">I think I found a quote in the n3485 C++ Working Draft that explains a tad more, in 3.8 [basic.life]:<br><br>5/ Before the lifetime of an object has started but after the storage which the object will occupy has been<br>
allocated or, after the lifetime of an object has ended and before the storage which the object occupied is<br>reused or released, any pointer that refers to the storage location where the object will be or was located<br>
may be used but only in limited ways. [...] The program has undefined behavior if:<br><br>[...]<br><br>— the pointer is used to access a non-static data member or call a non-static member function of the<br>object, or<br>
<br>[...]<br><br>— the pointer is used as the operand of a static_cast (5.2.9), except when the conversion is to pointer<br>to cv void, or to pointer to cv void and subsequently to pointer to either cv char or cv unsigned<br>
char, or<br><br>[...]<br><br><br></div><div class="gmail_extra">So unfortunately the scheme you are proposing is violating the Standard at least twice, because as far as the Standard goes your object is already dead (whether its destructor had any effect or not does not matter). Specifically, I could see one of `-fsanitize=undefined` or `-fsanitize=memory` (for example) overwriting the memory with 0xdeadbeef between the call to the destructor and the call to your specific operator delete.<br>
<br></div><div class="gmail_extra">I am sorry I had not remembered this point in our prior discussion; I had forgotten that operator new and operator delete are only supposed to deal with raw memory and not objects.<br><br>
</div><div class="gmail_extra">-- Matthieu<br></div></div>