Sterling's not as tough as he looks.
On Jul 23, 2004, at 5:05 PM, Ilia Alshanetsky wrote:
Fine fine... let's rever it... I don't feel like carrying brass
knuckles with
me all the time.
Ilia
On July 23, 2004 04:36 pm, Andi Gutmans wrote:
:)
Ilia, you heard the man. I don't think he leaves you much choice
unless you
want to risk him waiting for you in a dark alley with a surprise :)
Andi
At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
dooooooooooooooooooalllllllllocccccccccccccccccaaaaaaaaaaaaaaaaaaa,
damnit
On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]>
wrote:
At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 12:40 pm, you wrote:
At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 11:42 am, Andi Gutmans wrote:
Why do we need one extra byte?
We do not.
Anyway, the question is if we should return to alloca() or not.
I am
slightly in favor but don't feel very strongly about it.
Perhaps we could try a combination of the two, to ensure that no
script is
terminated due to a PHP crash if allocating on the stack fails.
By
default
we can use alloca() if that fails to allocate the memory, we
could use
emalloc() and set a flag free code indicating which free function
should
be used.
I'm hesitant to slow down the general case (even if it's just an
additional
if()) statement. I'd revert to alloca() and we can always add a
--paranoid-stack-allocation directive to configure to use
emalloc()
:)
The problem is that that this causes certain large script to just
crash, without any meaningful information. Is the cost of 2 if()s
really that pefromance prohibitive?
No it's not. But 2 and 2 and 2 is :)
I guess we can go with the if()'s for now.... Argh...
Want to write a patch?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
..I....I..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
