Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

"Sascha Schumann" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:<[EMAIL PROTECTED]>... > > 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,

RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

> 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

RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

> 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 th

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 an

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 > t

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

> 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 sing

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 vulnerb

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 T

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 co

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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)

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

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 mea

[PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

Sorry but just a thought, in that line: if (argc > 1 && (int)Z_STRLEN_P(return_value) < len / 2) { you're comparating len / 2 to an int, but len / 2 can be a float too no? Ignore me if I'm wrong... -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets