> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov <a...@webkit.org> wrote: > > > 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov <a...@webkit.org > <mailto:a...@webkit.org>> написал(а): > >> 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. > > Another way to say this is: we need to deal with large data arrays throughout > loading code. We do not really need full size vectors in most other code - > it's sort of OK for HTML parser or for image decoder to fail catastrophically > when there is too much data fed to it. > > This is somewhat questionable design, but if we are going to stick to it, > then magnitude checks should be centralized, not sprinkled throughout the > code. We should not make this check explicitly when feeding a network > resource to the parser, for example. > > A 64-bit API for Vector solves this nearly flawlessly. We do not perform the > checks manually every time we use a Vector, Vector does them for us. > > Other options are: > > - uint64_t everywhere. This way, we'll solve practical problems with large > resources once and for all. Also, this may prove to be necessary to solve > even YouTube/Google Drive uploads, I do not know that yet.
How does this solve the problem of >4GB data on 32-bit systems? Are you saying that because the code that measures file sizes uses a 64-bit type then therefore the code that measures memory object sizes should also use that same type? -Filip > > - size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones will > still be limited. I like this option, because it won't make us pay the memory > and performance cost on old crippled 32-bit machines, which are unlikely to > be used for manipulating huge volumes of data anyway. > > We'll also need to develop some magic for 53-bit JS bindings, which I'm not > sure about. > > - Alexey >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev