Added an ASSERT to catch an implausible but theoretically possible leak.
authorggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 6 Feb 2010 04:25:52 +0000 (04:25 +0000)
committerggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 6 Feb 2010 04:25:52 +0000 (04:25 +0000)
commit064d2f318f94ee4895b5aa8b76442c05bd9502d0
tree34d9cb627fd002bbf766b484e0ca455762015c1e
parent9fd44e71bcb61110fbfba9d751e94325c1c3f760
Added an ASSERT to catch an implausible but theoretically possible leak.

Reviewed by Dan Bernstein.

In theory, if malloc allocated a UChar buffer directly after a StringImpl,
the StringImpl might incorrecly assume that the UChar buffer was inline,
and fail to delete it.

This ASSERT is somewhat academic, since we don't use the same allocator
in debug builds, but oh well.

* platform/text/StringImpl.cpp:
(WebCore::StringImpl::StringImpl):
(WebCore::StringImpl::createUninitialized):
* platform/text/StringImpl.h: Separated the inline buffer StringImpl
constructor from the out-of-line buffer StringImpl constructor. Made
the former ASSERT that its buffer was indeed inline, and the latter ASSERT
that its buffer was indeed not inline.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@54460 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebCore/ChangeLog
WebCore/platform/text/StringImpl.cpp
WebCore/platform/text/StringImpl.h