I am fully aware that it can be made faster. But a slow solution is
better than no solution at all.
Actually in many situations it isn't. Since as far as I can see the
problem can lead to real harm only in rather limited set of situations,
making the engine always considerably slower just to f
> The function call does strike me as completely unnecessary and the additional
> stack operations required are expensive. I'm willing to be that if the
> function was converted to a macro, the proposed solution would be a workable
> fix. Just my two cents; I'm not very experienced with the PHP
On Sun, 20 May 2007, David wrote:
> The function call does strike me as completely unnecessary and the
> additional stack operations required are expensive. I'm willing to be
> that if the function was converted to a macro, the proposed solution
> would be a workable fix. Just my two cents; I'm
bench.php is a totally unrealistic benchmark that has nothing todo with
real life PHP applications. Of course when you call a function several
It tests the engine speed. Of course, in life of PHP script there are
other things, that's why I said "and" - to put it in context.
million times the
the vast mayority of users will be happy with a more secure system and
will like accept a 0.0.0.0.0.0.0.0.0.1% slowdown in case it is slow..
Sure, if only we knew that's not 10% slowdown.
I sometimes wonder what it is real target of PHP, the masses or a
selected neglible group of users that r
> I don't imagine how one really could calculate maximum depth without
> solving the halting problem, so I must be missing something. I ask
> somebody who knows what these patches are to send me a link - if there
> were patches that do that automatically for any code I would very much
> like to se
Hi,
I'm David Wang and I'm one of the students that is participating in Google
Summer of Code for this summer. My project addresses detecting reference cycles
in PHP, and I'm following this discussion because it seems very pertinent to
what I will be working with this summer. I'm currently plan
>
> Well, php test suite is a functional test, so if the patch is done
> correctly it'd pass of course. I'm moe worried about the performance -
> my experience shows that the guesses are often wrong when talked about
> performance effects in complicated code. If you would have time to run
> a benc
2007/5/21, Stanislav Malyshev <[EMAIL PROTECTED]>:
I'm moe worried about the performance -
the vast mayority of users will be happy with a more secure system and
will like accept a 0.0.0.0.0.0.0.0.0.1% slowdown in case it is slow..
I sometimes wonder what it is real target of PHP, the masses
no, no performance tests has been done over that patch, but as rasmus
said. it is probably negible or acceptable for real world.. I only
knows it works with real like code ( i tried ezpublish, phpmyadmin)
and passes the PHP test suite correctly ( or no worse than without the
patch)
Well, php tes
2007/5/21, Stanislav Malyshev <[EMAIL PROTECTED]>:
> at openSUSE, we also have a patch for this issue since a few weeks, as
> a vendor unfortunately we have to take care of things that people
> here dont want to fix...
>
> http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2
Did you
> You make things sound very black and white when they are usually grey.
>
You only don't realise how black things are.
> this is an acceptable performance tradeoff. We have to balance the
> seriousness of the vulnerability against the performance cost of the
>
Yeah well. Luckily since Suh
at openSUSE, we also have a patch for this issue since a few weeks, as
a vendor unfortunately we have to take care of things that people
here dont want to fix...
http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2
Did you perform the performance tests for this patch? What were the
In the other thread, where Stanislav spreads the usual lie/propaganda
that there is no help comming from me to the PHP developers, he also
claims
For the record - I never said that. I said that in that thread, as
in some of its predecessors, when it came from general discussion to the
substance
> Disclaimer: I don't know much about the way unicode is implemented in
> php, i have only used it a bit, but i believe i can clear some things
> up here.
>
>> 0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
>> utf-8. ą
>>
>> > var_dump("ą" == "\xC4\x85");
>> echo "ą\n";
>> echo
I don't see ANY reason bugs should be assigned by anybody other than the
person who is ACTUALLY working on it?
*IF* someone has time or has found a fix for a problem, THEY assign the
bug to them selves and put up the fix.
Well, there's a reason - not every developer watches bugs closely.
Thank
Stefan Esser wrote:
> The reason for this fix not being applied is not it's impossibility, but
> because the
> closed source extension developers (everyone knows who they are) don't want
> another binary compatibility break, because then their closed source
> extensions
> have to be shipped in yet
Disclaimer: I don't know much about the way unicode is implemented in
php, i have only used it a bit, but i believe i can clear some things
up here.
On 20/05/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in utf-8. ą
If script is
Cristian Rodriguez schrieb:
>> Here is the patch I created in approximately half an hour. A solution to
>> a problem
>
>> that is *NOT* fixable at the moment, according to Stanislav.
>
> at openSUSE, we also have a patch for this issue since a few weeks, as
> a vendor unfortunately we have to take
Here is the patch I created in approximately half an hour. A solution to
a problem
that is *NOT* fixable at the moment, according to Stanislav.
at openSUSE, we also have a patch for this issue since a few weeks, as
a vendor unfortunately we have to take care of things that people
here dont w
Hi Antony,
Would this change also apply to string_compare_function and
string_locale_compare_function? They currently use
zend_make_printable_zval()...
Matt
- Original Message -
From: "Antony Dovgal"
Sent: Thursday, May 17, 2007
> tony2001 Thu May 17 17:28:12 2007 UTC
>
> Modified
Hi Stas,
Can we see any difference with optimal ZEND_ADD_(STRING|CHAR|VAR)? :-)
Well, multiple ADD_STRINGs are one thing that optimizers/accelerators would
stitch back together, because it's a "major optimization." ;-) I didn't
specifically mention it in my previous messages, but since these part
Antony Dovgal wrote:
>>> Any chance to get GDB backtrace?
>
> Aha.. I see..
> Could you please try the patch attached?
Works.
Best regards,
Sebastian Nohn
--
Sebastian Nohn · Wolfstraße 29 · 53111 Bonn · Germany
+49-170-4718105 · http://nohn.net/ · [EMAIL PROTECTED]
http://pgpkeys.pca.dfn.de
Dear Kevin,
you are just ridiculous. Educate yourself WHO is responsible for
improved PHP security.
Stefan Esser
> This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
>
>
>> Stop flooding my inbox with your unqualified comments.
>> You can write the patch yourself, can you?
>>
Hello,
it is no secret that I am really sick and tired of this constant stream
of nonsense and
lies comming out of the mouths of PHP developers when it comes to
security issues.
In the other thread, where Stanislav spreads the usual lie/propaganda that
there is no help comming from me to the PHP
This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
> Stop flooding my inbox with your unqualified comments.
> You can write the patch yourself, can you?
> Or can't you? Then shut the fuck up.
I'm not the one whining about nothing being done.
This constant stream of dribble about
This one time, at band camp, Stefan Esser <[EMAIL PROTECTED]> wrote:
> The whole filter problematic is still unsolved. The filter hooks were
> still not moved into php_register_variable_ex so that they
> cannot be bypassed by mistake of a 3rd party PHP extension that
> implements another POST con
27 matches
Mail list logo
