On Sun, 5 Feb 2012 14:37:27 +0100, Pierre Joye wrote:
2012/2/5 Gustavo Lopes <glo...@nebm.ist.utl.pt>:
All the length and position variables are of type size_t, so I'd
say
we'd be out of memory long before that could be a problem (unless
there's some architecture of which I'm not aware where SIZE_T is
low
enough for this to be a problem).
read: SIZE_MAX, not SIZE_T
By the way, SIZE_MAX (can be up to 65k or so afair) should not be
used
in relation with buffer (string or other) length. It defines the
maximum size of a single object allocation that the compiler can
manage. Not sure if it is actually what you want here.
SIZE_MAX is indeed the limit of size_t. See ISO/IEC 9899:TC3, section
7.18.3 on http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
(page 259).
Forgetting the irrelevant case where size_t is 16 bit wide, there is
indeed a potential problem if size_t is 32-bit wide. First, if you can
pass a string with about 2GB you could the multiplication by 2 would
wrap around. But you could even pass a smaller string (possibly 10/15
times less, I don't know what's the maximum expansion factor of
htmlentities) and then it could wrap in the reallocation. I'll take this
into account.
--
Gustavo Lopes
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
