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
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, 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
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, 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
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
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]
