<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - CString should be more consistent about disallowing null bytes"
   href="https://bugs.webkit.org/show_bug.cgi?id=144339">144339</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>CString should be more consistent about disallowing null bytes
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>WebKit
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>528+ (Nightly build)
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Unspecified
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Unspecified
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>Normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P2
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Web Template Framework
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>webkit-unassigned&#64;lists.webkit.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>ap&#64;webkit.org
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>darin&#64;apple.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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 <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - REGRESSION (r183373): ASSERT failed in wtf/SHA1.h"
   href="show_bug.cgi?id=144257">bug 144257</a>, another is <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Frequent crashes in CFURLCache code on Snow Leopard"
   href="show_bug.cgi?id=55412">bug 55412</a>, 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&lt;uint8_t&gt;. 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 <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - REGRESSION (r183373): ASSERT failed in wtf/SHA1.h"
   href="show_bug.cgi?id=144257">bug 144257</a>:

CString functions that work properly with embedded null characters:

    data
    mutableData
    length
    isNull
    isSafeToSendToAnotherThread
    buffer
    isHashTableDeletedValue
    == (when both sides are CString)

Functions that do not:

    hash
    &lt;
    == (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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>