[Webkit-unassigned] [Bug 144339] CString should be more consistent about disallowing null bytes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=144339

--- Comment #3 from Darin Adler <darin at apple.com> ---
Yes, I agree with you about the assertion, which is why I pushed you to remove the it.

I think Alexey would prefer that we move away from CString for any case where we want to allow null characters and use CString only for cases where we do not want to allow them. I think I agree; it’s messy to null-terminate a string if we know that there might be a null character inside it!

I’m not sure how we are going to find all those call sites that need to handle null characters before we remove support from CString. I’m also not sure that I prefer we use Vector<char>, Vector<uint8_t> or something else that doesn’t waste extra memory on capacity, since we won’t be resizing these once they are created. Also note that CString implements a shared handle to a string. Good because you can share without copying. Bad because we always pay the overhead of a pointer, extra memory block, and reference counting. I could even imagine creating a class that shares CStringBuffer with CString, but doesn’t do the null termination thing rather than using Vector. Really not sure.

I think WTF::String::utf8 should fail when there is a null character, returning a null CString as it does when it fails due to other kinds of conversion errors.

The WTF::String::latin1 and WTF::String::ascii functions are already OK in this respect. They may have other problems, but they never produce a string with a null character in it.

I believe TextCodec::encode may produce null characters, so it is probably one of the call sites that needs to change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150429/016ac4a9/attachment.html>