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