Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime

2003-01-28 Thread nicos 
Yes, you should remove that note.

--
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.

"Maxim Maletsky" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
>
> Derick Rethans <[EMAIL PROTECTED]> wrote... :
>
> > On Tue, 28 Jan 2003, Maxim Maletsky wrote:
> >
> > >
> > > A user posted this note below.
> > >
> > > I do not know Catalan and cannot check it myself, however I decided
not
> > > to ignore it and ask if anyone on the dev list could confirm that the
> > > user makes sense.
> > >
> > > If he does, then what?
> >
> > It wouldn't be a bug in PHP, but in the locales installed on his system
> > I guess.
> >
> > Derick
>
> In fact, I did guess that. Anything we can do, though? At least, I think
> we should remove his note as it is unrelated to other locale's
> installations.
>
> --
> Maxim Maletsky
> [EMAIL PROTECTED]
>
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Brian Moon 
Give me a patch and I will tell you. ;)

Brian Moon
dealnews.com


- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Joseph Tate" <[EMAIL PROTECTED]>
Cc: "Brian Moon" <[EMAIL PROTECTED]>; "Php-Dev List"
<[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
Sent: Tuesday, January 28, 2003 4:03 PM
Subject: RE: [PHP-DEV] Re: Register Shutdown Function for Apache


| At 19:54 28/01/2003, Joseph Tate wrote:
| >Then, could we add a sapi_flush()/ob_flush() call at the end of
| >apache_php_module_main after calling the normal
register_shutdown_functions?
|
| Yeah, something along these lines.
|
| >What else might have problems?
|
| Might is a powerful word :)
|
| Zeev
|
|
|


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Zeev Suraski 
At 19:54 28/01/2003, Joseph Tate wrote:

Then, could we add a sapi_flush()/ob_flush() call at the end of
apache_php_module_main after calling the normal register_shutdown_functions?


Yeah, something along these lines.


What else might have problems?


Might is a powerful word :)

Zeev


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Joseph Tate 
Then, could we add a sapi_flush()/ob_flush() call at the end of
apache_php_module_main after calling the normal register_shutdown_functions?
What else might have problems?

Joseph

> -Original Message-
> From: Brian Moon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 11:23 AM
> To: Brian Moon; [EMAIL PROTECTED]; Joseph Tate
> Cc: Php-Dev List; PHP Group
> Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
>
>
> It also does not send the headers if there is not content.
>
> 
> header("Location: http://spidey.dealnews.com/";);
>
> exit();
>
> ?>
>
>
>
> Document Contains No Data.
>
>
>
> Brian.
>
> dealnews.com
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Brian Moon 
It also does not send the headers if there is not content.

http://spidey.dealnews.com/";);

exit();

?>



Document Contains No Data.



Brian.

dealnews.com


- Original Message -
From: "Brian Moon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Joseph Tate" <[EMAIL PROTECTED]>
Cc: "Php-Dev List" <[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
Sent: Tuesday, January 28, 2003 10:16 AM
Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache


| You are correct.  The output buffer is not auto-flushed with this patch.
|
| Brian.
| dealnews.com
|
| - Original Message -
| From: "Zeev Suraski" <[EMAIL PROTECTED]>
| To: "Joseph Tate" <[EMAIL PROTECTED]>
| Cc: "Php-Dev List" <[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
| Sent: Tuesday, January 28, 2003 3:16 AM
| Subject: [PHP-DEV] Re: Register Shutdown Function for Apache
|
|
| | Joseph,
| |
| | Your latest patch seems to be in the right direction (admittedly I
haven't
| | reviewed it until now).  A couple of random points:
| |
| | - It sounds dangerous to me to move php_request_shutdown() to be called
| | from Apache's shutdown without further inspection.  At least one thing
| | comes to mind - won't it screw up output buffers (they're supposed to
| | autoflush on shutdown, and if I'm not mistaken, this autoflush will now
| | happen when the connection is already closed)?  Possibly some other
things
| too.
| | - Once we're all happy with the patch, we need to decide what to do with
| | it.  Right now, there are no plans to release any further 4.x versions,
| | except for bug fixes.  And the question arises - should this change be
in
| a
| | bugfix release or not.  It certainly has potential to screw things up.
| |
| | Zeev
| |
| | At 18:38 23/01/2003, Joseph Tate wrote:
| | >I can have the patches ready to go in a very short amount of time.
I'll
| | >work on and post them if I can be reasonably sure they'll be committed.
| I'm
| | >tired of spinning my wheels with this though.  I've got a personally
| patched
| | >version of 4.3.0 that will be going into production in a few weeks, so
| I'm
| | >confident in the changes.  I'd like to not use a personally patched
| version
| | >of PHP the next time a release comes down the pipe though.  As a
| reminder,
| | >this patch will fix bug #15209 without breaking the new functionality
of
| | >register_shutdown_function under !apache systems.
| | >
| | >I've appealed to the [EMAIL PROTECTED] for karma to apply them myself, but
| for
| | >the last two weeks have heard nothing either negative or positive.
| | >
| | >Joseph
| |
| |
| | --
| | PHP Development Mailing List 
| | To unsubscribe, visit: http://www.php.net/unsub.php
| |
| |
| |
|
|
| --
| PHP Development Mailing List 
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime

2003-01-28 Thread Maxim Maletsky 

Derick Rethans <[EMAIL PROTECTED]> wrote... :

> On Tue, 28 Jan 2003, Maxim Maletsky wrote:
> 
> > 
> > A user posted this note below.
> > 
> > I do not know Catalan and cannot check it myself, however I decided not
> > to ignore it and ask if anyone on the dev list could confirm that the
> > user makes sense.
> > 
> > If he does, then what?
> 
> It wouldn't be a bug in PHP, but in the locales installed on his system
> I guess.
> 
> Derick

In fact, I did guess that. Anything we can do, though? At least, I think
we should remove his note as it is unrelated to other locale's
installations.

--
Maxim Maletsky
[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime

2003-01-28 Thread Derick Rethans 
On Tue, 28 Jan 2003, Maxim Maletsky wrote:

> 
> A user posted this note below.
> 
> I do not know Catalan and cannot check it myself, however I decided not
> to ignore it and ask if anyone on the dev list could confirm that the
> user makes sense.
> 
> If he does, then what?

It wouldn't be a bug in PHP, but in the locales installed on his system
I guess.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime

2003-01-28 Thread Maxim Maletsky 

A user posted this note below.

I do not know Catalan and cannot check it myself, however I decided not
to ignore it and ask if anyone on the dev list could confirm that the
user makes sense.

If he does, then what?

Maxim Maletsky
[EMAIL PROTECTED]



Forwarded by Maxim Maletsky <[EMAIL PROTECTED]>
--- Original Message ---
From:"Iván"@rack1.php.net
To:  [EMAIL PROTECTED]
Date:28 Jan 2003 15:07:31 -
Subject: [PHP-NOTES] note 28935 added to function.strftime


PHP contains a bug in the Catalan (ca_ES) locale, as it has "decembre" for "december", 
when it should be "desembre".

It also affects to the abbreviation "dec", which should be "des".

Take this into account if you're coding locale-dependant for Catalan display 
settings...
-- 
http://www.php.net/manual/en/function.strftime.php
http://master.php.net/manage/user-notes.php?action=edit+28935
http://master.php.net/manage/user-notes.php?action=delete+28935
http://master.php.net/manage/user-notes.php?action=reject+28935


-- 
PHP Notes Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


- Original Message Ends 


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Brian Moon 
You are correct.  The output buffer is not auto-flushed with this patch.

Brian.
dealnews.com

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Joseph Tate" <[EMAIL PROTECTED]>
Cc: "Php-Dev List" <[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
Sent: Tuesday, January 28, 2003 3:16 AM
Subject: [PHP-DEV] Re: Register Shutdown Function for Apache


| Joseph,
|
| Your latest patch seems to be in the right direction (admittedly I haven't
| reviewed it until now).  A couple of random points:
|
| - It sounds dangerous to me to move php_request_shutdown() to be called
| from Apache's shutdown without further inspection.  At least one thing
| comes to mind - won't it screw up output buffers (they're supposed to
| autoflush on shutdown, and if I'm not mistaken, this autoflush will now
| happen when the connection is already closed)?  Possibly some other things
too.
| - Once we're all happy with the patch, we need to decide what to do with
| it.  Right now, there are no plans to release any further 4.x versions,
| except for bug fixes.  And the question arises - should this change be in
a
| bugfix release or not.  It certainly has potential to screw things up.
|
| Zeev
|
| At 18:38 23/01/2003, Joseph Tate wrote:
| >I can have the patches ready to go in a very short amount of time.  I'll
| >work on and post them if I can be reasonably sure they'll be committed.
I'm
| >tired of spinning my wheels with this though.  I've got a personally
patched
| >version of 4.3.0 that will be going into production in a few weeks, so
I'm
| >confident in the changes.  I'd like to not use a personally patched
version
| >of PHP the next time a release comes down the pipe though.  As a
reminder,
| >this patch will fix bug #15209 without breaking the new functionality of
| >register_shutdown_function under !apache systems.
| >
| >I've appealed to the [EMAIL PROTECTED] for karma to apply them myself, but
for
| >the last two weeks have heard nothing either negative or positive.
| >
| >Joseph
|
|
| --
| PHP Development Mailing List 
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Segmention fault in HEAD (zend_hash_find)

2003-01-28 Thread Zeev Suraski 
Fixed.

At 08:04 28/01/2003, Magnus Määttä wrote:

Hi!

This code produces this segfault under HEAD.




bt ( for the whole bt: http://novell.stoldgods.nu/~magnus/bt ):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31900)]
0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 , nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
873 HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht, 
idx, pData));
(gdb) bt
#0  0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 , nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
#1  0x0823bf0b in do_bind_function (opline=0x418a3334, 
function_table=0x83bbdb4, class_table=0x83bbe64, compile_time=1)
at /opt/DEV/php/php5/Zend/zend_compile.c:1703
#2  0x0823c331 in zend_do_early_binding () at 
/opt/DEV/php/php5/Zend/zend_compile.c:1792
#3  0x0822a55b in zendparse () at 
/opt/DEV/php/php5/Zend/zend_language_parser.y:155
#4  0x0822fd8d in compile_file (file_handle=0xb800, type=2) at 
/opt/DEV/php/php5/Zend/zend_language_scanner.l:297
#5  0x0824c75e in zend_execute_scripts (type=8, retval=0x0, file_count=3) 
at /opt/DEV/php/php5/Zend/zend.c:992
#6  0x08213907 in php_execute_script (primary_file=0xb800) at 
/opt/DEV/php/php5/main/main.c:1691
#7  0x0826dbfd in main (argc=2, argv=0xb894) at 
/opt/DEV/php/php5/sapi/cli/php_cli.c:753
#8  0x40a7fa44 in __libc_start_main () from /lib/libc.so.6
(gdb) bt full
#0  0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 , nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
tmp = 0x1 
h = 1099587512
nIndex = 1099587512
p = (struct bucket *) 0x418d1ffc
#1  0x0823bf0b in do_bind_function (opline=0x418a3334, 
function_table=0x83bbdb4, class_table=0x83bbe64, compile_time=1)
at /opt/DEV/php/php5/Zend/zend_compile.c:1703
function = (union _zend_function *) 0x831b4a0
#2  0x0823c331 in zend_do_early_binding () at 
/opt/DEV/php/php5/Zend/zend_compile.c:1792
opline = (struct _zend_op *) 0x418a3334
#3  0x0822a55b in zendparse () at 
/opt/DEV/php/php5/Zend/zend_language_parser.y:155
zendchar = -2
zendlval = {op_type = 1, throw_list = 0x0, u = {constant = {value 
= {lval = 138932069, dval = 4.3126331443290903e-314,
str = {val = 0x847ef65 "\n\n}", len = 2}, ht = 0x847ef65, obj = 
{handle = 138932069, handlers = 0x2}}, refcount = 1,
  type = 1 '\001', is_ref = 0 '\0'}, var = 138932069, opline_num = 
138932069, op_array = 0x847ef65,
previously_active_class_entry = 0x847ef65, jmp_addr = 0x847ef65, EA = 
{var = 138932069, type = 2}}}
zendnerrs = 0
yystate = 71
yyn = 6
yyresult = 0
yyerrstatus = 0
yychar1 = 137
yyssa = {0, 1, 2, 71, 139, 246, 373, 458, 515, 563, 617, 656, 
686, 709, 58, 0, 19124, 16686, 15188, 16385, 16124, 16385,
  -12431, 2055, -11392, -16385, 28976, 16384, -12431, 2055, -29767, 1801, 
24900, 2054, -11472, -16385, 16048, 16385, 58, 0, 19392,
  16686, 0, 0, 1, 0 , 30240, 27745, -17521, 0, -17440, 
2107, -11480, -16385, -10352, 2085, -17448, 2107, 12736,
  16778, 12644, 16569, -11384, -16385, 12736, 16778, -4548, 2, -11432, 
-16385, -11713, 2085, -18957, 0, -17440, 2107, -11432,
  -16385, -10352, 2085, -17448, 2107, 18480, 16778, -17184, 2107, 12620, 
16778, 18480, 16778, -10292, 2, -11384, -16385, -11713,
  2085, -17448, 2107, 12796, 16778, 5684, 0, 5684, 0, 12808, 16778, 1421, 
0, 12668, 16778, 12796, 16778, 0, 0, 5684, 0, -11336,
  -16385, 27860, 2083, 18476, 16778, -25604, 2105, 4, 0, -10352, 2085, 
-17448, 2107, 12796, 16778, 12844, 16778, 704, 0, 5632, 0,
  12808, 16778, -11288, -16385, 28348, 2083, 5632, 0, -20800, 2097, 48, 
0, 0, 0, 0, 0, 12844, 16778, -17184, 2107, 12736, 16778, 0,
  0, 60, 0, -11240, -16385, 16830, 2084, 0, 0, 5632, 0, 0, 0, -20800, 2097}
yyss = (short int *) 0xbfffd270
yyssp = (short int *) 0xbfffd276

around 60k more after that..


Regards
Magnus Määttä

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-28 Thread Rasmus Lerdorf 
> Don't you have any FreeBSD kernel hackers in Y!?  You could probably
> convince/bully one of them to fix it, that's what we always do with ours
> here ;-)

Turns out that one of the problems is that the standard 0x80 way of doing 
a syscall is rather slow on the P4 chip.  P3 and Athlon chips are much 
faster.  As of Linux kernel 2.5.57 or so they are now using sysenter which 
is much quicker, but FreeBSD is still using 0x80 on the P4.  This article 
has some interesting info on the subject:

   http://lwn.net/Articles/18411/

In the end it looks like I am simply going to turn off realpath() 
completely in virtual_file_ex() which means of course that if 
include_once/require_once is used to access the same file through two 
different paths due to a symlink, things will break.  And you can symlink 
your way out of an open_basedir restriction.  I'll happily trade those 
things for the extra 40-50 req/sec this is likely to give me.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Another segfault running pear installer

2003-01-28 Thread Edin Kadribasic 
$ gdb sapi/cli/php
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r  -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php
/data/src/php5/pear/package-*.xml
Starting program: /data/src/php5/sapi/cli/php -n -dsafe_mode=0
/data/src/php5/pear/install-pear.php
/data/src/php5/pear/package-*.xml

Warning: Invalid argument supplied for foreach() in
/data/src/php5/pear/PEAR/Registry.php on line 489
/data/src/php5/pear/PEAR/Registry.php(489) : Warning - Invalid
argument supplied for foreach()

Warning: Cannot use a scalar value as an array in
/data/src/php5/pear/PEAR/Installer.php on line 682
/data/src/php5/pear/PEAR/Installer.php(682) : Warning - Cannot use a
scalar value as an array

Warning: Invalid argument supplied for foreach() in
/data/src/php5/pear/PEAR/Installer.php on line 682
/data/src/php5/pear/PEAR/Installer.php(682) : Warning - Invalid
argument supplied for foreach()

Program received signal SIGSEGV, Segmentation fault.
0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0,
codeptr=0x1,
ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc,
reqcharptr=0x402c73bc,
bcptr=0x1, cd=0x402b1ce4) at
/data/src/php5/ext/pcre/pcrelib/pcre.c:2708
2708previous[1] = length;
(gdb) bt
#0  0x080817b9 in compile_branch (optionsptr=0x402be350,
brackets=0x0, codeptr=0x1,
ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc,
reqcharptr=0x402c73bc,
bcptr=0x1, cd=0x402b1ce4) at
/data/src/php5/ext/pcre/pcrelib/pcre.c:2708
#1  0x0816c0fc in zend_do_fcall_common_helper
(execute_data=0xbfffb0b0,
op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2630
#2  0x0816c43c in zend_do_fcall_by_name_handler
(execute_data=0xbfffb0b0,
op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2694
#3  0x081677e2 in execute (op_array=0x402d5ac4)
at /data/src/php5/Zend/zend_execute.c:1217
#4  0x0816c0fc in zend_do_fcall_common_helper
(execute_data=0xbfffd630,
op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2630
#5  0x0816c43c in zend_do_fcall_by_name_handler
(execute_data=0xbfffd630,
op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2694
#6  0x081677e2 in execute (op_array=0x400af464)
at /data/src/php5/Zend/zend_execute.c:1217
#7  0x081569f6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /data/src/php5/Zend/zend.c:996
#8  0x08123479 in php_execute_script (primary_file=0xb960)
at /data/src/php5/main/main.c:1691
#9  0x081727bc in main (argc=7, argv=0xba04)
at /data/src/php5/sapi/cli/php_cli.c:753
#10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Derick Rethans 
On Tue, 28 Jan 2003, Zeev Suraski wrote:

> Your latest patch seems to be in the right direction (admittedly I haven't 
> reviewed it until now).  A couple of random points:
> 
> - It sounds dangerous to me to move php_request_shutdown() to be called 
> from Apache's shutdown without further inspection.  At least one thing 
> comes to mind - won't it screw up output buffers (they're supposed to 
> autoflush on shutdown, and if I'm not mistaken, this autoflush will now 
> happen when the connection is already closed)?  Possibly some other things too.
> - Once we're all happy with the patch, we need to decide what to do with 
> it.  Right now, there are no plans to release any further 4.x versions, 
> except for bug fixes.  And the question arises - should this change be in a 
> bugfix release or not.  It certainly has potential to screw things up.

I don't favor merging this to the PHP_4_3 branch, as it seems a huge 
change. (And it's broken for quite some time anyway).

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Register Shutdown Function for Apache

2003-01-28 Thread Zeev Suraski 
Joseph,

Your latest patch seems to be in the right direction (admittedly I haven't 
reviewed it until now).  A couple of random points:

- It sounds dangerous to me to move php_request_shutdown() to be called 
from Apache's shutdown without further inspection.  At least one thing 
comes to mind - won't it screw up output buffers (they're supposed to 
autoflush on shutdown, and if I'm not mistaken, this autoflush will now 
happen when the connection is already closed)?  Possibly some other things too.
- Once we're all happy with the patch, we need to decide what to do with 
it.  Right now, there are no plans to release any further 4.x versions, 
except for bug fixes.  And the question arises - should this change be in a 
bugfix release or not.  It certainly has potential to screw things up.

Zeev

At 18:38 23/01/2003, Joseph Tate wrote:
I can have the patches ready to go in a very short amount of time.  I'll
work on and post them if I can be reasonably sure they'll be committed.  I'm
tired of spinning my wheels with this though.  I've got a personally patched
version of 4.3.0 that will be going into production in a few weeks, so I'm
confident in the changes.  I'd like to not use a personally patched version
of PHP the next time a release comes down the pipe though.  As a reminder,
this patch will fix bug #15209 without breaking the new functionality of
register_shutdown_function under !apache systems.

I've appealed to the [EMAIL PROTECTED] for karma to apply them myself, but for
the last two weeks have heard nothing either negative or positive.

Joseph



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php