On Jun 12, 2012, at 3:03 PM, Myles C. Maxfield <[email protected]> wrote:
> I noticed that this caused a problem in one particular place > (WTF::StringImpl::getData16SlowCase()) where the code allocates (constant * > length) bytes for an (empty) string, and provides an accessor that exposes > this pointer. This pointer was being passed to ICU, which didn't perform the > requested function because it looked like one of the arguments was invalid, > even though it was just empty. I don’t think we should generalize from this one case to a requirement that malloc(0) return a pointer. In the case you describe, it’s the ICU behavior is what seems strange to me. Almost all other libraries would be happy to take a null pointer and a length to represent a string of zero length. I suggest we put workaround close to the site of that strangeness. I would not object to having that workaround in place even though most platforms won’t run into the problem due to malloc behavior. I think that Eric’s interest was in greater efficiency by changing our designs to avoid doing malloc(0). I have no strong objection to that either, but it seems worthwhile only if the cost is really significant. -- Darin _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
