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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 28 10:48:18 PDT 2015


            Bug ID: 144339
           Summary: CString should be more consistent about disallowing
                    null bytes
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ap at webkit.org
                CC: darin at apple.com

CString is a class that we use to guarantee having a null character at the end, and to simplify memory management of C strings.

In the past, we had multiple bugs caused by its confusing handling of embedded null characters. CString doesn't enforce the no nulls policy, but some of its methods, and also some of its callers don't work with embedded nulls.

One example is bug 144257, another is bug 55412, and I remember something very similar to the latter occurring on Windows.

I think that conceptually, CString should not allow null bytes, and when we need actual data arrays, we should use Vector<uint8_t>. It does not make sense to use a class that ensures a trailing null with data that has embedded nulls.

However, I'm not sure how we would use CString in conjunction with String, as Strings can have null bytes. But then again, we probably have a serious bug in every place where we convert a String to a CString using e.g. latin1() or utf8(), so revisiting all these places would make sense.

Darin noted this in bug 144257:

CString functions that work properly with embedded null characters:

    == (when both sides are CString)

Functions that do not:

    == (when one side is a CString and the other is a const char*)

It’s clear that we should either forbid the embedded null characters entirely, or make the functions all support them.

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/20150428/e0d48301/attachment.html>

More information about the webkit-unassigned mailing list