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 <[email protected]> wrote: > > > 19 нояб. 2014 г., в 13:58, Filip Pizlo <[email protected] > <mailto:[email protected]>> написал(а): > >>> 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 >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
