delete does not reset the pointer in GCC (4.6.0)

Hi,

some time ago we removed all lines that looked like that

delete xyz;
xyz = 0;

by just

delete xyz;

because GCC resets the pointer to zero.

But actually it doesn't seem to do that. I was testing std::auto_ptr for  
another project and accidentally added a
delete xyz
twice.

The program crashed. I wrote a simple test program to verify this, and GCC  
never resets the pointer:


#include <iostream>
#include <memory>

class MyBase {
public:
        virtual bool doSomething() {
                std::cout << "done something...!" << std::endl;
                return true;
        }
};

int main() {
        MyBase* my = new MyBase();
        delete my;
        std::cout << "pointer: " << my << std::endl;
        if (my  == 0)
        {
                std::cout << "aha" << std::endl;
        }

        return 0;
}


The program never reaches the if block and the cout gives me an actual  
pointer address.
Is it a bug in GCC 4.6.0 or does GCC really not reset the pointer.

As we made the change months ago, I said that some compilers do not reset  
the pointer, somebody meant that every known compiler does.
Well GCC doesn't (anymore)  :-)


Can you confirm this?

Andi

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> some time ago we removed all lines that looked like that
>
> delete xyz;
> xyz = 0;

Are you really sure about this? I hope not. Because I would agree that crashes immediately...

Didnt we change
if (xyz) delete xyz;
to
delete xyz;
?


--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Yes we changed your scenario, too.
But we also changed the code I described before. Maybe this is longer than  
a few months ago, maybe 2 years.
I know that I always added
xyz = 0;
to my code before, but then it was removed again because it is not  
neccessary with modern compilers (I don't know who said that).




On Wed, 15 Jun 2011 10:30:56 +0200, Marcel Wiesweg <[hidden email]>  
wrote:

>
>> some time ago we removed all lines that looked like that
>>
>> delete xyz;
>> xyz = 0;
>
> Are you really sure about this? I hope not. Because I would agree that  
> crashes immediately...
>
> Didnt we change
> if (xyz) delete xyz;
> to
> delete xyz;
> ?
>
>

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

What' about an GCC option to handle pointers properly, and reset to zero after delete. It's a question of course...

Gilles Caulier

2011/6/15 Andi Clemens <[hidden email]>

Yes we changed your scenario, too.
But we also changed the code I described before. Maybe this is longer than
a few months ago, maybe 2 years.
I know that I always added
xyz = 0;
to my code before, but then it was removed again because it is not
neccessary with modern compilers (I don't know who said that).




On Wed, 15 Jun 2011 10:30:56 +0200, Marcel Wiesweg <[hidden email]>
wrote:

>
>> some time ago we removed all lines that looked like that
>>
>> delete xyz;
>> xyz = 0;
>
> Are you really sure about this? I hope not. Because I would agree that
> crashes immediately...
>
> Didnt we change
> if (xyz) delete xyz;
> to
> delete xyz;
> ?
>
>


--

Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________

Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> a few months ago, maybe 2 years.
> I know that I always added
> xyz = 0;
> to my code before, but then it was removed again because it is not  
> neccessary with modern compilers (I don't know who said that).

When googling and reading through the usual sources (stackoverflow etc.) I see noone saying that any compiler sets a pointer to 0, I would even guess delete should _not_ change the value of the passed pointer unless the C++ standard says so.
There are the usual stories not to use raw pointers and use concepts to make sure you are always sure never to use deleted pointers again, but in the end, if you are playing with raw pointers (which we are doing still in too many areas IMO, but getting less) and need to delete and reuse the variable, be sure to set it to 0.

Marcel
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Right, we are still using too many raw pointers.
Qt, C++ stdlib and boost have many things to handle pointers automatically.

See Item #13 in "Effective C++": Use objects to manage resources
A great book, everyone should read it...

Anyway sure auto_ptr and friends will "slow" down execution, but with all  
the checks we do anyway, I guess it will not be noticeable.
It is still much faster than garbage collection...

Andi


On Wed, 15 Jun 2011 11:55:50 +0200, Marcel Wiesweg <[hidden email]>  
wrote:

>
>> a few months ago, maybe 2 years.
>> I know that I always added
>> xyz = 0;
>> to my code before, but then it was removed again because it is not
>> neccessary with modern compilers (I don't know who said that).
>
> When googling and reading through the usual sources (stackoverflow etc.)  
> I see noone saying that any compiler sets a pointer to 0, I would even  
> guess delete should _not_ change the value of the passed pointer unless  
> the C++ standard says so.
> There are the usual stories not to use raw pointers and use concepts to  
> make sure you are always sure never to use deleted pointers again, but  
> in the end, if you are playing with raw pointers (which we are doing  
> still in too many areas IMO, but getting less) and need to delete and  
> reuse the variable, be sure to set it to 0.
>
> Marcel

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2011/6/15 Andi Clemens <[hidden email]>

Right, we are still using too many raw pointers.
Qt, C++ stdlib and boost have many things to handle pointers automatically.

Yes. this one is exactly that we need :

http://doc.qt.nokia.com/4.7/qpointer.html 

See Item #13 in "Effective C++": Use objects to manage resources
A great book, everyone should read it...

Do you have an url ?

 

Anyway sure auto_ptr and friends will "slow" down execution, but with all
the checks we do anyway, I guess it will not be noticeable.
It is still much faster than garbage collection...

Perhaps we will need to patch code about to use QPointer everywhere when it's necessary...

Gilles 

 

Andi


On Wed, 15 Jun 2011 11:55:50 +0200, Marcel Wiesweg <[hidden email]>
wrote:

>

>> a few months ago, maybe 2 years.
>> I know that I always added
>> xyz = 0;
>> to my code before, but then it was removed again because it is not
>> neccessary with modern compilers (I don't know who said that).
>
> When googling and reading through the usual sources (stackoverflow etc.)
> I see noone saying that any compiler sets a pointer to 0, I would even
> guess delete should _not_ change the value of the passed pointer unless
> the C++ standard says so.
> There are the usual stories not to use raw pointers and use concepts to
> make sure you are always sure never to use deleted pointers again, but
> in the end, if you are playing with raw pointers (which we are doing
> still in too many areas IMO, but getting less) and need to delete and
> reuse the variable, be sure to set it to 0.
>
> Marcel


--

Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________

Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Francesco Riosa]

On Wednesday 15 June 2011 11:55:50 Marcel Wiesweg wrote:

> > a few months ago, maybe 2 years.
> > I know that I always added
> > xyz = 0;
> > to my code before, but then it was removed again because it is not
> > neccessary with modern compilers (I don't know who said that).
>
> When googling and reading through the usual sources (stackoverflow etc.) I
> see noone saying that any compiler sets a pointer to 0, I would even guess
> delete should _not_ change the value of the passed pointer unless the C++
> standard says so. There are the usual stories not to use raw pointers and
> use concepts to make sure you are always sure never to use deleted pointers
> again, but in the end, if you are playing with raw pointers (which we are
> doing still in too many areas IMO, but getting less) and need to delete and
> reuse the variable, be sure to set it to 0.
>
> Marcel

Disclaimer I do know nothing of c++ remember? please do take it in account.

This excided my curiosity too, and I've booth gcc-4.5 and 4.6 installed so
tested the program below.

As far as I can see gcc does nothing to put a 0 in the pointer, neither in 4.5
version, it does add a check before the "delete" call to avoid deleting a 0
pointer but nothing else.

you can search for label "startLookingAtMe" in the gimple code attached
(gimple is a low level rappresentation of the code used by gcc internally)


#include <iostream>

/*
g++-4.5.2 -O0 -ggdb3 -fdump-tree-gimple a.cpp \
&& mv a.cpp.004t.gimple a.cpp.004t.gcc45.gimple
g++-4.6.0 -O0 -ggdb3 -fdump-tree-gimple a.cpp \
&& mv a.cpp.004t.gimple a.cpp.004t.gcc46.gimple

# to compare use:
sed -i -e 's:[0-9][0-9][0-9][0-9][0-9]:99999:g' a.*.gimple

NO CHANGES g++-4.6.0 -O0 -fno-delete-null-pointer-checks -ggdb3 -fdump-tree-
gimple a.cpp && mv a.cpp.004t.gimple a.cpp.004t.gcc46dncp.gimple
*/

using namespace std;

main()
{
        int * p;
        p= new (nothrow) int[2];
        p[0] = 1; p[1] = 2;
        for (int n=0; n<2; n++)
                cout << p[n] << ", ";
        cout << endl;
startLookingAtMe:
        delete[] p;
        p = 0; // omitting this crashes
        delete[] p;
        if (p) delete p;
endLookingAtMe:
        cout << (0/0); // my easy brakpoint
}


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Francesco Riosa]

On Wednesday 15 June 2011 14:17:37 Gilles Caulier wrote:

> 2011/6/15 Andi Clemens <[hidden email]>
>
> > Right, we are still using too many raw pointers.
> > Qt, C++ stdlib and boost have many things to handle pointers
> > automatically.
>
> Yes. this one is exactly that we need :
>
> http://doc.qt.nokia.com/4.7/qpointer.html
>
> > See Item #13 in "Effective C++": Use objects to manage resources
> > A great book, everyone should read it...
>
> Do you have an url ?

This may be of interest:
http://labs.qt.nokia.com/2009/08/25/count-with-me-how-many-smart-pointer-
classes-does-qt-have/

for some more fun I've converted the previous example to use QPointer and
QObject, it's at the end of the mail.

>
> > Anyway sure auto_ptr and friends will "slow" down execution, but with
> > all
> > the checks we do anyway, I guess it will not be noticeable.
> > It is still much faster than garbage collection...
>
> Perhaps we will need to patch code about to use QPointer everywhere when
> it's necessary...
>
> Gilles
>
> > Andi
> >
> >
> > On Wed, 15 Jun 2011 11:55:50 +0200, Marcel Wiesweg
> > <[hidden email]>
> >
> > wrote:
> > >> a few months ago, maybe 2 years.
> > >> I know that I always added
> > >> xyz = 0;
> > >> to my code before, but then it was removed again because it is not
> > >> neccessary with modern compilers (I don't know who said that).
> > >
> > > When googling and reading through the usual sources (stackoverflow
> > > etc.) I see noone saying that any compiler sets a pointer to 0, I
> > > would even guess delete should _not_ change the value of the passed
> > > pointer unless the C++ standard says so.
> > > There are the usual stories not to use raw pointers and use concepts
> > > to
> > > make sure you are always sure never to use deleted pointers again,
> > > but
> > > in the end, if you are playing with raw pointers (which we are doing
> > > still in too many areas IMO, but getting less) and need to delete
> > > and
> > > reuse the variable, be sure to set it to 0.
> > >
> > > Marcel

#include <iostream>
#include <QtCore/QObject>
#include <QtCore/QPointer>

/*
g++-4.5.2 -I /usr/include/qt4 -L/usr/lib64/qt4 -lQtCore -O0 -ggdb3 -fdump-
tree-gimple b.cpp && mv b.cpp.004t.gimple b.cpp.004t.gcc45.gimple
g++-4.6.0 -I /usr/include/qt4 -L/usr/lib64/qt4 -lQtCore -O0 -ggdb3 -fdump-
tree-gimple b.cpp && mv b.cpp.004t.gimple b.cpp.004t.gcc46.gimple

# to compare use:
sed -i -e 's:[0-9][0-9][0-9][0-9][0-9]:99999:g' b.*.gimple

*/

using namespace std;

// QPointer<QLabel> label = new QLabel;
//      label->setText("&Status:");
//      ...
//      if (label)
//          label->show();

main()
{
        QPointer<QObject> p = new QObject;
        p->dumpObjectInfo();

startLookingAtMe:
        delete p;
        // p = 0; // omitting DOES NOT crash
        delete p;
        if (p) delete p;
endLookingAtMe:
        cout << (0/0); // my easy brakpoint
}

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > Right, we are still using too many raw pointers.
> > Qt, C++ stdlib and boost have many things to handle pointers
> > automatically.
>
> Yes. this one is exactly that we need :
>
> http://doc.qt.nokia.com/4.7/qpointer.html

QPointer is good for QObject pointers, but works only with them

Where applicable, "value" classes can be built around implicit sharing
(QSharedDataPointer), like DImageHistory recently. It's some lines extra but
100% safe to crashes if the class itself checks for 0. Of course, there is
overhead for the extra allocation, but almost all Qt value classes are built
around this pattern, beginning with QString or QByteArray.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Wed, 15 Jun 2011 14:17:37 +0200, Gilles Caulier  
<[hidden email]> wrote:

>> See Item #13 in "Effective C++": Use objects to manage resources
>> A great book, everyone should read it...
>>
>>
> Do you have an url ?
>

It is a real book, so the only link I can give you is
http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876/ref=sr_1_1?ie=UTF8&qid=1308179068&sr=8-1

Even if you are a long time C++ programmer, some of the tipps in this book  
might be things you never heard of, I learned a lot.

Andi


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Matthias Welwarsky]

On Wednesday 15 June 2011 10:42:31 Andi Clemens wrote:
> Yes we changed your scenario, too.
> But we also changed the code I described before. Maybe this is longer than
> a few months ago, maybe 2 years.
> I know that I always added
> xyz = 0;
> to my code before, but then it was removed again because it is not
> neccessary with modern compilers (I don't know who said that).

I'd be very surprised if any compiler ever did that.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel