[webkit-reviews] review requested: [Bug 171405] Add StringView::toExistingAtomicString() : [Attachment 308479] Patch

[bugzilla-daemon at webkit.org]

Daniel Bates <dbates at webkit.org> has asked  for review:
Bug 171405: Add StringView::toExistingAtomicString()
https://bugs.webkit.org/show_bug.cgi?id=171405

Attachment 308479: Patch

https://bugs.webkit.org/attachment.cgi?id=308479&action=review




--- Comment #1 from Daniel Bates <dbates at webkit.org> ---
Created attachment 308479

  --> https://bugs.webkit.org/attachment.cgi?id=308479&action=review

Patch

Is there a reason for the AtomicStringImpl::lookUp() functions taking a
non-const pointer to a LChar/UChar? I mean, AtomicStringImpl does not mutate
the LChar/UChar* buffer passed when performing a lookup. I am unclear how we
came to the decision to have these functions (formerley named
AtomicString::find()) take non-const pointers to buffers other than to match
the non-constness of the buffer passed by the callers that motiviated the
addition of these lookup functions in <http://trac.webkit.org/changeset/168256>
(bug #132548). We seemed to explicitly avoid making these lookup functions take
a const pointer to a buffer and added AtomicString::findInternal() when we
later moved and renamed AtomicString::find() to AtomicStringImpl::lookUp() in
<https://trac.webkit.org/changeset/182915> (bug #43404). Why?