There is a clear order and size relation between m_buffer and m_segments. With m_dataArray, there is the implicit rule that m_dataArray comes after m_buffer and m_segments, and all segments are completely full. In practice, we never mix m_dataArray and m_segments (well, I hope at least) which is why that works. We should make those relations explicit. Related to: <rdar://problem/10801705>
<rdar://problem/10808108>
Updating title. m_buffer is still needed even with data array. Also taking bug since I have a patch.
Created attachment 176814 [details] Patch
Created attachment 200453 [details] Patch
Comment on attachment 200453 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=200453&action=review > Source/WebCore/platform/SharedBuffer.cpp:211 > + m_buffer.reserveInitialCapacity(length); I don't think that matters. The append() call has the size, it will allocate the best block size for the input.
Comment on attachment 200453 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=200453&action=review >> Source/WebCore/platform/SharedBuffer.cpp:211 >> + m_buffer.reserveInitialCapacity(length); > > I don't think that matters. The append() call has the size, it will allocate the best block size for the input. That change was inspired by <http://trac.webkit.org/changeset/135098> made for bug 102625
Hmm.. Looks like I never checked this in. :( I am going to rebase the patch, make sure it works and maybe upload a new one for review.
Looks like the patch compiles and runs fine with USE(NETWORK_CFDATA_ARRAY_CALLBACK) disabled. If it works fine with the flag turned on, I'll just go ahead and commit.
Committed r154823: <http://trac.webkit.org/changeset/154823>