[webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Chris Dumez]

If we don’t want to crash on overflow, the callers can use the try*() API I believe (e.g. tryAppend()). This returns false (and does not resize the vector) instead of crashing, when we reach the size limit.

Kr,
--
Chris Dumez - Apple Inc.
Cupertino, CA




> On Nov 19, 2014, at 2:58 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 
> 
> 19 нояб. 2014 г., в 13:58, Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> написал(а):
> 
>>> With Vector though, I don't know how we would differentiate code paths that need large allocations from ones that don't. Nearly anything that is exposed as a JS API or deals with external world can hit sizes over 4Gb. That's not out of reach in most scenarios, not even for resources loaded from network.
>> 
>> Can you provide an example?
> 
> Yes. XMLHttpRequest::m_binaryResponseBuilder keeps the downloaded data in a Vector, so any time there is much data, something bad will happen. This is a case that we should support, and not just crash as we would when we think that only exploits would try to use as much memory.
> 
> All code that is Blob related also uses Vectors, and of course Blobs can legitimately be large.
> 
> Crypto code uses Vectors internally for the data.
> 
> These and related uses are all over the place - see also Vectors in FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, plug-in code that loads from network, SharedBuffer etc.
> 
> - Alexey
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141119/7a96e03e/attachment.html>