This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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