iirc the reason why i changed it to unsigned was that actually the zend engine
treated it as unsigned everywhere but in that particular struct. i also
remember that i discussed that with andi and that he agreed to change this in
the ze2 cvs module and that the extensions should be *fixed*. i agree
On Wed, Jan 15, 2003 at 06:36:20PM +0100, Harald Radi wrote:
iirc the reason why i changed it to unsigned was that actually the zend engine
treated it as unsigned everywhere but in that particular struct. i also
remember that i discussed that with andi and that he agreed to change this in
the
On Wed, 15 Jan 2003, Harald Radi wrote:
iirc the reason why i changed it to unsigned was that actually the zend engine
treated it as unsigned everywhere but in that particular struct. i also
remember that i discussed that with andi and that he agreed to change this in
the ze2 cvs module and
From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
iirc the reason why i changed it to unsigned was that
actually the zend engine
treated it as unsigned everywhere but in that particular
struct. i also
remember that i discussed that with andi and that he agreed
to change this in
you're propably a bit too optimistic, i can hardly imagine that all existing
extensions all over the world compile out of the box against ZE2. i guess only
a handful do this.
Apparently, most of the extensions PHP ships with seem to
work out of the box. I'm under the impression that
I might be misunderstanding the problem and I didn't have time to read the
phrack article, but doesn't this mean that leaving it unsigned is better?
It wouldn't pass the length check and thus, memcpy() wouldn't convert a
negative number to something huge.
The problem is that every single
On Sat, 11 Jan 2003, Ilia A. wrote:
On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote:
On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote:
Sorry but just a thought, in that line:
if (argc 1 (int)Z_STRLEN_P(return_value) len / 2) {
Does this mean we now always
On Sat, Jan 11, 2003 at 05:56:23PM -0500, Ilia A. wrote:
On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote:
On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote:
Sorry but just a thought, in that line:
if (argc 1 (int)Z_STRLEN_P(return_value) len / 2) {
Does this
On Sat, Jan 11, 2003 at 11:59:49PM +0100, Sascha Schumann wrote:
Does this mean we now always need to cast the result of the
Z_STRLEN_P/Z_STRLEN_PP macros to int? That seems pretty annoying and not to
producing ugly code.
Certainly not.
What kind of warnings was the compiler
The cause for this is that phanto changed the type of the
string length from a signed type to zend_uint without
providing any kind of justification (zvalue_value).
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities
I imagine that strings greater then 2 billion characters are fairly rare, so I
think it would be a good idea to revert the change as per Sascha's
suggestion. This is a fairly old limitation and I think no one will miss this
feature.
Ilia
--
PHP Development Mailing List http://www.php.net/
To
On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities in
software (recent examples include MySQL, OpenBSD kernel).
Actually codes like below produce vulnerble
On Sun, 12 Jan 2003, Moriyoshi Koizumi wrote:
On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities in
software (recent examples include MySQL, OpenBSD
At 12:38 AM 1/12/2003 +0100, Sascha Schumann wrote:
On Sun, 12 Jan 2003, Moriyoshi Koizumi wrote:
On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities in
14 matches
Mail list logo
