rasmus Sun, 05 Feb 2012 09:32:20 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323070
Log:
According to the reports on qa this test is failing the same way for everyone.
See:
http://qa.php.net/reports/viewreports.php?version=5.3.10&test=%2Fext
rasmus Sun, 05 Feb 2012 09:50:14 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323071
Log:
Getting different hashes here. But this test isn't testing the hashes,
it is just making sure we actually get a hash and don't crash.
Changed paths:
rasmus Sun, 05 Feb 2012 09:52:41 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323072
Log:
Need EXPECTF here, of course
Changed paths:
U php/php-src/branches/PHP_5_3/ext/openssl/tests/bug47828.phpt
U php/php-src/branches/PHP_5_4/ex
mariuz Sun, 05 Feb 2012 09:58:50 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323073
Log:
fix gcov Warning: ibase_drop_db(): lock time-out on wait transaction object
http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests&file=ext%2Fpdo_fir
cataphract Sun, 05 Feb 2012 09:59:33 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323074
Log:
- Merge r323056 (see bug #60965).
Bug: https://bugs.php.net/60965 (Critical) Buffer overflow on
htmlspecialchars/entities with $double=false
Cha
rasmus Sun, 05 Feb 2012 10:08:16 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323075
Log:
Another openssl test that is dependent on the openssl version. The output has
changed in more recent versions. Synch with newer output and consider chang
rasmus Sun, 05 Feb 2012 10:29:34 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323076
Log:
Without a timezone you can't know whether it is dst or not in this one
Changed paths:
U
php/php-src/branches/PHP_5_3/ext/intl/tests/dateformat_pa
rasmus Sun, 05 Feb 2012 10:35:56 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323077
Log:
Same thing here. "June 18, 1969 8:49:59 AM " does not contain a timezone, so
there
is no way to know whether dst should be applied or not.
Changed path
I didn't carefully review this patch, but doesn't this code suffer from
potential math overflow?
i.e. with strlen($input_str) > INT_MAX/2 (or UINT_MAX/2)
Nuno
- Original Message -
From: "Gustavo André dos Santos Lopes"
To:
Sent: Sunday, February 05, 2012 9:59 AM
Subject: [PHP-CVS]
cataphract Sun, 05 Feb 2012 11:45:01 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323078
Log:
- Connection: close, not "closed".
Changed paths:
U php/php-src/trunk/sapi/cli/php_cli_server.c
Modified: php/php-src/trunk/sapi/cli/php_cli_serv
On Sun, 5 Feb 2012 10:55:39 -, Nuno Lopes wrote:
I didn't carefully review this patch, but doesn't this code suffer
from potential math overflow?
i.e. with strlen($input_str) > INT_MAX/2 (or UINT_MAX/2)
All the length and position variables are of type size_t, so I'd say
we'd be out of m
On Sun, 05 Feb 2012 14:00:11 +0100, Gustavo Lopes wrote:
On Sun, 5 Feb 2012 10:55:39 -, Nuno Lopes wrote:
I didn't carefully review this patch, but doesn't this code suffer
from potential math overflow?
i.e. with strlen($input_str) > INT_MAX/2 (or UINT_MAX/2)
All the length and position
2012/2/5 Gustavo Lopes :
>> 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, n
On Sun, 5 Feb 2012 14:37:27 +0100, Pierre Joye wrote:
2012/2/5 Gustavo Lopes :
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 fo
cataphract Sun, 05 Feb 2012 14:57:57 +
Revision: http://svn.php.net/viewvc?view=revision&revision=323079
Log:
- Fixed possible unsigned int wrap around in html.c. Note that 5.3 has the same
(potential) problem; even though the code is substantially different, t
On Sun, 05 Feb 2012 15:00:11 +0100, Gustavo Lopes wrote:
On Sun, 5 Feb 2012 14:37:27 +0100, Pierre Joye wrote:
2012/2/5 Gustavo Lopes :
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 architect
On Sun, 05 Feb 2012 15:00:11 +0100, Gustavo Lopes wrote:
On Sun, 5 Feb 2012 14:37:27 +0100, Pierre Joye wrote:
2012/2/5 Gustavo Lopes :
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 architectu
17 matches
Mail list logo
