Re: svn: /php/php-src/branches/PHP_5_ 4/ NEWS ext/standard/html.c ext/standard/tests/string s/bug60965.phpt
| From: | Gustavo Lopes | Date: | Sun, 05 Feb 2012 15:02:52 +0000 |
| Subject: | Re: svn: /php/php-src/branches/PHP_5_ 4/ NEWS ext/standard/html.c ext/standard/tests/string s/bug60965.phpt | ||
| References: | 1 2 3 4 5 6 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-67638@lists.php.net to get a copy of this message | ||
On Sun, 05 Feb 2012 15:00:11 +0100, Gustavo Lopes wrote:
On Sun, 5 Feb 2012 14:37:27 +0100, Pierre Joye wrote:See http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/html.c?r1=323079&r2=323078&pathrev=323079 I don't know if this is worth merging to 5.4 at this point; after all 5.3 has the same problem. -- Gustavo Lopes2012/2/5 Gustavo Lopes <glopes@nebm.ist.utl.pt>: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.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.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