fstreams Bug (memory error)
Martin v. Loewis
martin@loewis.home.cs.tu-berlin.de
Sun Feb 6 03:22:00 GMT 2000
> The fstreams now have a bug in them which causes them to attempt to
> delete NULL. I don't know if this is because they are double
> deleting, or just deleting a NULL in general, but it seems to be a
> common error in the fstreambase class or lower. It doesn't show up
> in programs usually because the normal version of delete[] ignores
> requests to delete NULL, however we are overloading the normal
> memory management routines and so we found the bug through our
> version of delete.
Thanks for your bug report. I fail to see the bug, though, 0 is a
legal argument for operator delete. 3.7.3.2,
[basic.stc.dynamic.deallocation]/3 says
# The value of the first argument supplied to one of the deallocation
# functions provided in the standard library may be a null pointer
# value; if so, the call to the deallocation function has no effect.
So the bug is in your implementation of operator delete, if it does
not handle a null pointer.
In case you wonder where the call originates from: it is in
inline ios::~ios() {
#ifndef _IO_NEW_STREAMS
if (!(_flags & (unsigned int)ios::dont_close)) delete rdbuf();
#endif
// It is safe to use naked operator delete[] as we know elements have no
// dtor, and g++ does not add a new[] cookie for such cases.
operator delete[] (_arrays);
}
Hope this helps,
Martin
More information about the Gcc-bugs
mailing list