Fwd: Re: deleting null pointer arrays (was: Re: extragear/network/ktorrent)

[Olivier Goffart]

Le vendredi 16 janvier 2009, Michael Pyne a écrit :
> On Thursday 15 January 2009, Dominik Haumann wrote:
> > Hi,
> >
> > according to [1] this change is wrong:
> > >>         BitSet & BitSet::operator = (const BitSet & bs)
> > >>         {
> > >> -               if (data)
> > >> -                       delete [] data;
> > >> +               delete [] data
> >
> > Still, it seems to be unclear whether that's sill an issue.
> > Does anyone have an idea?
> >
> > Dominik
> >
> > [1]
> > http://techbase.kde.org/Development/Tutorials/Common_Programming_Mistakes
> >#N ULL_pointer_issues
>
> The way delete [] works is that the size of the array is embedded somewhere
> in the array to be deleted (handled by the corresponding new[]).  delete[]
> uses this information to free the array appropriately.
>
> Apparently the "recent Solaris compiler" does not check for 0 before trying
> to find the hidden array length.
>
> Section 5.3.5 of the C++ standard seems to define what happens when delete
> is called, and says that delete doing nothing for null pointers applies for
> both delete and delete[].  So the Solaris compiler has a bug.
>
> Whether or not we want to work around it is a different story but delete[]
> on a null pointer is perfectly valid C++.

Maybe we can workaround it with something like this in some header:

#ifdef BROKEN_OPERATOR_DELETE
void operator delete[] (void *p)
{
	if(!p)	return;
	::delete[] p;  //FIXME: call the real delete[]
}
#endif


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090116/96a36a86/attachment.sig>