This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: C++ PATCH: Warn on deleting void *
- To: mark@codesourcery.com
- Subject: Re: C++ PATCH: Warn on deleting void *
- From: Nathan Sidwell <nathan@acm.org>
- Date: Fri, 16 Apr 1999 10:01:28 +0100
- CC: nathan@compsci.bristol.ac.uk, egcs-patches@egcs.cygnus.com, libstdc++@sourceware.cygnus.com
- Organization: University of Bristol
- References: <37162070.530670CE@acm.org> <199904151757.KAA09483@adsl-206-170-148-33.dsl.snfc21.pacbell.net>
- Reply-To: nathan@compsci.bristol.ac.uk
Mark Mitchell wrote:
> Actually, shouldn't the libio change be:
>
> operator delete[](_arrays)
>
> rather than:
>
> operator delete (_arrays)?
oops, you are correct. _But_ libio would still appear to be relying on
implementation defined behaviour. _arrays is allocated as `new T[e]'
(ioextend.cc/get_array_element) where T is a POD struct. This is array new, so
array delete should be used, as you point out. 5.3.4/10 says the implementation
has liberty to allocate more space for vector new (secrete a cookie, so
delete[] knows how many dtors to call). We only add the cookie, if the type has
a dtor (or the delete[] takes a size operand), so libio's usage is ok. The
second half of 5.3.4/10 indicates that even `new char[e]' can have a cookie. We
do not document this feature - perhaps we should ...
I'll let the libstdc++ list know.
nathan
--
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
You can up the bandwidth, but you can't up the speed of light
nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk