rniwa at webkit.org
Wed Jun 13 13:14:44 PDT 2012
On Wed, Jun 13, 2012 at 12:48 PM, Myles C. Maxfield <
myles.maxfield at gmail.com> wrote:
> I think the fact that ICU thinks that a null pointer is an invalid string
> isn't necessarily an incorrect one. It's just a quirk of an interface to a
> library. I don't think that a good solution is to change the interface of
> ICU and try to upstream a patch to ICU
Certainly not since not all browsers ship with their own ICU embedded
I see two different solutions:
> 1) Document the fact that, in order to use webkit, you need an
> implementation of malloc(0) that doesn't return null pointers. This way,
> the burden of solving this problem is pushed downstream.
I don't think we should impose arbitrary requirements like this.
> 2) Find some place along the every pipeline from malloc(0) to ICU, and
> arbitrarily modify the pointer to a non-zero value. This is probably the
> best solution, but a real fix of this nature requires finding all the
> places where pointers can be passed into ICU.
We already have an abstraction layer for all ICU functions in WTF and
WebCore/platform because not all ports use ICU (e.g. Qt port). It should be
fairly easy to add an extra code there to check whether a null pointer is
passed in or not and bail out as appropriate.
If I solve (via option 2) just my one particular occurrence of this
> problem, I see three different places to arbitrarily modify the pointer
> given to ICU:
> 1) change the m_copyData16 pointer in StringImpl to an arbitrary value,
> and check for that arbitrary value on destruction
> 2) change the characters() accessor to check if m_copyData16 is null, and
> return an arbitrary value if it is. This works because callers of
> characters() shouldn't ever delete the pointer nor dereference the pointer
> (since the string's length is 0)
> 3) check for null at the call site of the ICU function.
> I (perhaps prematurely) uploaded a CL implementing<https://bugs.webkit.org/show_bug.cgi?id=88936>option 2. What do you think?
Adding any code to characters() will likely impact performance because it
tends to be used in hot code paths so I'd rather avoid that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev