Re: [PHP-DEV] Libtool for RH8
Derick, would you post the SRPM for libtool? Joseph Derick Rethans wrote: On 19 Feb 2003, michel 'ziobudda' morelli wrote: Hi, i have downloaded the new cvs version of php5, but: buildconf: libtool version 1.4.2 found. You need libtool version 1.4.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 where I can find it ? there is no update for redhat for libtool 1.4.3 ah, I already made them: http://files.derickrethans.nl/libtool-1.4.3-4.i386.rpm http://files.derickrethans.nl/libtool-libs-1.4.3-4.i386.rpm Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Register Shutdown Function for Apache
Thanks Jani. I'll work on getting the patch working on HEAD and PHP_4_3
this afternoon.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Jani Taskinen
Sent: Thursday, February 13, 2003 2:49 AM
To: Brian Moon
Cc: Joseph Tate; Php-Dev List
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
There is now 'HAVE_APACHE' defined when you configure with apache.
(dso or static)
--Jani
On Tue, 11 Feb 2003, Brian Moon wrote:
Jani, are you volunteering to add it? If so, please do so at
your earliest
convience.
Brian Moon
dealnews.com
- Original Message -
From: Jani Taskinen [EMAIL PROTECTED]
To: Joseph Tate [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 6:16 PM
Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
|
| If you need a define for it, we can add one..?
|
| --Jani
|
|
| On Mon, 10 Feb 2003, Joseph Tate wrote:
|
| Well, to me, calling the code that flushes the headers and the output
| buffers twice doesn't kill us. Unless someone can come up
with a better
way
| to not call these two functions in
main/main.c::php_request_shutdown, the
| patch suffices for me. MOD_PHP4_H is undefined in main.c, so it's not
| acceptable.
|
| Joseph
|
| -Original Message-
| From: Brian Moon [mailto:[EMAIL PROTECTED]]
| Sent: Monday, February 03, 2003 5:30 PM
| To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
| Cc: Php-Dev List
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h.
Not real
| descriptive, but seems to be unique to the Apache sapi.
|
| Brian Moon
| dealnews.com
|
|
| - Original Message -
| From: Joseph Tate [EMAIL PROTECTED]
| To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED];
| [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Cc: Php-Dev List [EMAIL PROTECTED]
| Sent: Monday, February 03, 2003 3:45 PM
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| | Here is an updated patch which copies a few of the methods from
| | main/main.c::php_request_shutdown to
| | sapi/apache/sapi_apache.c::apache_php_module_main. This has
| flushed both
| | the headers and output buffers in my two test scripts.
Now I need to
| figure
| | out a way to make sure these don't get called in
| | main/main.c::php_request_shutdown on Apache systems. Any
pointers on
| this?
| | Is there a handy #define that I can use if configure is
| called --with-apxs?
| |
| | Joseph
| |
| | P.S. The two test scripts are:
| |
| | ?PHP
| | header('Location: http://www.mi-corporation.com');
| | exit();
| | ?
| |
| | and
| |
| | ?PHP
| | ob_begin();
| | phpinfo();
| | ?
| |
| | -Original Message-
| | From: Brian Moon [mailto:[EMAIL PROTECTED]]
| | Sent: Tuesday, January 28, 2003 5:50 PM
| | To: [EMAIL PROTECTED]; Joseph Tate
| | Cc: Php-Dev List; PHP Group
| | Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
| |
| |
| | 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 http://www.php.net/
| | To unsubscribe, visit: http://www.php.net/unsub.php
| |
| |
| |
| |
|
|
|
|
|
|
|
| --
| - For Sale! -
|
|
| --
| PHP Development Mailing List http://www.php.net/
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|
--
- For Sale! -
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Register Shutdown Function for Apache
I think it's reached that stage. Something like HAVE_APXS that's defined
when configure is called --with-apxs. That'd be great.
Joseph
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Jani Taskinen
Sent: Monday, February 10, 2003 7:16 PM
To: Joseph Tate
Cc: Php-Dev List
Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
If you need a define for it, we can add one..?
--Jani
On Mon, 10 Feb 2003, Joseph Tate wrote:
Well, to me, calling the code that flushes the headers and the output
buffers twice doesn't kill us. Unless someone can come up with
a better way
to not call these two functions in main/main.c::php_request_shutdown, the
patch suffices for me. MOD_PHP4_H is undefined in main.c, so it's not
acceptable.
Joseph
-Original Message-
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 5:30 PM
To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Php-Dev List
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h. Not real
descriptive, but seems to be unique to the Apache sapi.
Brian Moon
dealnews.com
- Original Message -
From: Joseph Tate [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 3:45 PM
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
| Here is an updated patch which copies a few of the methods from
| main/main.c::php_request_shutdown to
| sapi/apache/sapi_apache.c::apache_php_module_main. This has
flushed both
| the headers and output buffers in my two test scripts. Now I need to
figure
| out a way to make sure these don't get called in
| main/main.c::php_request_shutdown on Apache systems. Any pointers on
this?
| Is there a handy #define that I can use if configure is
called --with-apxs?
|
| Joseph
|
| P.S. The two test scripts are:
|
| ?PHP
| header('Location: http://www.mi-corporation.com');
| exit();
| ?
|
| and
|
| ?PHP
| ob_begin();
| phpinfo();
| ?
|
| -Original Message-
| From: Brian Moon [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, January 28, 2003 5:50 PM
| To: [EMAIL PROTECTED]; Joseph Tate
| Cc: Php-Dev List; PHP Group
| Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
|
|
| 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 http://www.php.net/
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|
|
--
- For Sale! -
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Register Shutdown Function for Apache
You're right. I suppose both --with-apache and --with-apxs will have to
define HAVE_APACHE or something similar.
-Original Message-
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 11:14 AM
To: Joseph Tate; Jani Taskinen
Cc: Php-Dev List
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
Well, it is not just apxs is it? The same would be true if --with-apache
was used.
Brian Moon
dealnews.com
- Original Message -
From: Joseph Tate [EMAIL PROTECTED]
To: Jani Taskinen [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 9:04 AM
Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
| I think it's reached that stage. Something like HAVE_APXS
that's defined
| when configure is called --with-apxs. That'd be great.
|
| Joseph
|
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
| Behalf Of Jani Taskinen
| Sent: Monday, February 10, 2003 7:16 PM
| To: Joseph Tate
| Cc: Php-Dev List
| Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
|
|
|
| If you need a define for it, we can add one..?
|
| --Jani
|
|
| On Mon, 10 Feb 2003, Joseph Tate wrote:
|
| Well, to me, calling the code that flushes the headers and the output
| buffers twice doesn't kill us. Unless someone can come up with
| a better way
| to not call these two functions in main/main.c::php_request_shutdown,
the
| patch suffices for me. MOD_PHP4_H is undefined in main.c,
so it's not
| acceptable.
|
| Joseph
|
| -Original Message-
| From: Brian Moon [mailto:[EMAIL PROTECTED]]
| Sent: Monday, February 03, 2003 5:30 PM
| To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
| Cc: Php-Dev List
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| Hmm, there is #define MOD_PHP4_H in
sapi/apache/mod_php4.h. Not real
| descriptive, but seems to be unique to the Apache sapi.
|
| Brian Moon
| dealnews.com
|
|
| - Original Message -
| From: Joseph Tate [EMAIL PROTECTED]
| To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED];
| [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Cc: Php-Dev List [EMAIL PROTECTED]
| Sent: Monday, February 03, 2003 3:45 PM
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| | Here is an updated patch which copies a few of the methods from
| | main/main.c::php_request_shutdown to
| | sapi/apache/sapi_apache.c::apache_php_module_main. This has
| flushed both
| | the headers and output buffers in my two test scripts.
Now I need
to
| figure
| | out a way to make sure these don't get called in
| | main/main.c::php_request_shutdown on Apache systems.
Any pointers
on
| this?
| | Is there a handy #define that I can use if configure is
| called --with-apxs?
| |
| | Joseph
| |
| | P.S. The two test scripts are:
| |
| | ?PHP
| | header('Location: http://www.mi-corporation.com');
| | exit();
| | ?
| |
| | and
| |
| | ?PHP
| | ob_begin();
| | phpinfo();
| | ?
| |
| | -Original Message-
| | From: Brian Moon [mailto:[EMAIL PROTECTED]]
| | Sent: Tuesday, January 28, 2003 5:50 PM
| | To: [EMAIL PROTECTED]; Joseph Tate
| | Cc: Php-Dev List; PHP Group
| | Subject: Re: [PHP-DEV] Re: Register Shutdown Function
for Apache
| |
| |
| | 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 http://www.php.net/
| | To unsubscribe, visit: http://www.php.net/unsub.php
| |
| |
| |
| |
|
|
|
|
|
|
|
| --
| - For Sale! -
|
|
|
|
|
| --
| PHP Development Mailing List http://www.php.net/
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe
RE: [PHP-DEV] Register Shutdown Function for Apache
Well, to me, calling the code that flushes the headers and the output
buffers twice doesn't kill us. Unless someone can come up with a better way
to not call these two functions in main/main.c::php_request_shutdown, the
patch suffices for me. MOD_PHP4_H is undefined in main.c, so it's not
acceptable.
Joseph
-Original Message-
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 5:30 PM
To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Php-Dev List
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h. Not real
descriptive, but seems to be unique to the Apache sapi.
Brian Moon
dealnews.com
- Original Message -
From: Joseph Tate [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 3:45 PM
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
| Here is an updated patch which copies a few of the methods from
| main/main.c::php_request_shutdown to
| sapi/apache/sapi_apache.c::apache_php_module_main. This has
flushed both
| the headers and output buffers in my two test scripts. Now I need to
figure
| out a way to make sure these don't get called in
| main/main.c::php_request_shutdown on Apache systems. Any pointers on
this?
| Is there a handy #define that I can use if configure is
called --with-apxs?
|
| Joseph
|
| P.S. The two test scripts are:
|
| ?PHP
| header('Location: http://www.mi-corporation.com');
| exit();
| ?
|
| and
|
| ?PHP
| ob_begin();
| phpinfo();
| ?
|
| -Original Message-
| From: Brian Moon [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, January 28, 2003 5:50 PM
| To: [EMAIL PROTECTED]; Joseph Tate
| Cc: Php-Dev List; PHP Group
| Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
|
|
| 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 http://www.php.net/
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|
|
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bug #21279 Karma request (Windows Bug)
You need to use C style /*comments*/. Also, send a unified diff. Do this by running cvs diff -u files you modified. Joseph -Original Message- From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #21279 Karma request (Windows Bug) Hi Rasmus, A Few months ago I was willing to help in bug fixes and bcompiler development I solved the bug #21279 and now I need karma to commit my changes there I debbuged the file with the help of Manuel Lemos and I found the bug. Here is the diff: 1615: // Z_STRVAL_P(tmp) = empty_string; 1616: ZVAL_NULL(tmp); 1626: // Z_STRVAL_P(tmp) = empty_string; 1627: ZVAL_NULL(tmp); TIA and HTH, Ernani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Register Shutdown Function for Apache
Here is an updated patch which copies a few of the methods from
main/main.c::php_request_shutdown to
sapi/apache/sapi_apache.c::apache_php_module_main. This has flushed both
the headers and output buffers in my two test scripts. Now I need to figure
out a way to make sure these don't get called in
main/main.c::php_request_shutdown on Apache systems. Any pointers on this?
Is there a handy #define that I can use if configure is called --with-apxs?
Joseph
P.S. The two test scripts are:
?PHP
header('Location: http://www.mi-corporation.com');
exit();
?
and
?PHP
ob_begin();
phpinfo();
?
-Original Message-
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 5:50 PM
To: [EMAIL PROTECTED]; Joseph Tate
Cc: Php-Dev List; PHP Group
Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
? php4/ext/mysql/.libs
? php4/main/.main.c.swp
? php4/sapi/apache/.sapi_apache.c.swp
Index: php4/ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -r1.543.2.4 basic_functions.c
--- php4/ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ php4/ext/standard/basic_functions.c 3 Feb 2003 21:32:05 -
@@ -1121,6 +1121,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -2085,32 +2086,28 @@
}
}
-void php_call_shutdown_functions(void)
+PHPAPI void php_call_shutdown_functions(HashTable ** names)
{
TSRMLS_FETCH();
- if (BG(user_shutdown_function_names))
+ if (*names){
zend_try {
- zend_hash_apply(BG(user_shutdown_function_names),
(apply_func_t) user_shutdown_function_call TSRMLS_CC);
+ zend_hash_apply(*names, (apply_func_t)
+user_shutdown_function_call TSRMLS_CC);
memcpy(EG(bailout), orig_bailout, sizeof(jmp_buf));
- zend_hash_destroy(BG(user_shutdown_function_names));
- efree(BG(user_shutdown_function_names));
+ zend_hash_destroy(*names);
+ efree(*names);
+ *names = NULL;
}
- zend_end_try();
+ zend_end_try();
+ }
}
-/* {{{ proto void register_shutdown_function(string function_name)
- Register a user-level function to be called on request termination */
-PHP_FUNCTION(register_shutdown_function)
+PHPAPI void register_shutdown_function_entry(HashTable ** names, int ht, zval *
+return_value)
{
php_shutdown_function_entry shutdown_function_entry;
int i;
- shutdown_function_entry.arg_count = ZEND_NUM_ARGS();
-
- if (shutdown_function_entry.arg_count 1) {
- WRONG_PARAM_COUNT;
- }
+ shutdown_function_entry.arg_count = (ht);
shutdown_function_entry.arguments = (pval **) emalloc(sizeof(pval *)
*shutdown_function_entry.arg_count);
@@ -2118,14 +2115,26 @@
RETURN_FALSE;
}
if (!BG(user_shutdown_function_names)) {
- ALLOC_HASHTABLE(BG(user_shutdown_function_names));
- zend_hash_init(BG(user_shutdown_function_names), 0, NULL, (void
(*)(void *)) user_shutdown_function_dtor, 0);
+ ALLOC_HASHTABLE(*names);
+ zend_hash_init(*names, 0, NULL, (void (*)(void *))
+user_shutdown_function_dtor, 0);
}
for (i = 0; i shutdown_function_entry.arg_count; i++) {
shutdown_function_entry.arguments[i]-refcount++;
}
- zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
+ zend_hash_next_index_insert(*names, shutdown_function_entry,
+sizeof(php_shutdown_function_entry), NULL);
+ RETURN_TRUE;
+}
+
+/* {{{ proto void register_shutdown_function(string function_name)
+ Register a user-level function
RE: [PHP-DEV] Re: Register Shutdown Function for Apache
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. ?php header(Location: http://spidey.dealnews.com/;); exit(); ? Document Contains No Data. Brian. dealnews.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Register Shutdown Function for Apache
For your reference, and all others on the list, here are the patches against
the 4.3.0 release code. See the original post at
http://lists.php.net/article.php?group=php.devarticle=93238. If someone
e-mails me to say they'll commit the changes, I'll make the patches to head
and the 4.3 branch, but as of yet, noone's spoken up. I'll not waste any
more cycles on this until I get a positive response. So far there are three
yes votes and no negative votes.
Joseph
-Original Message-
From: George Schlossnagle [mailto:[EMAIL PROTECTED]]
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
What is the current state of the patches? I know there where a couple
implementations discussed and discarded. It would seem to me to be
impossible to endorse commiting them without seeing their current
state. If the current patch you're running against 4.3.0 has been
posted elsewhere on the list, my apologies and can you send a link to
the archives for it?
? php4/ext/mysql/.libs
Index: php4/ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -b -r1.543.2.4 basic_functions.c
--- php4/ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ php4/ext/standard/basic_functions.c 7 Jan 2003 21:00:30 -
@@ -1121,6 +1121,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -2085,32 +2086,28 @@
}
}
-void php_call_shutdown_functions(void)
+PHPAPI void php_call_shutdown_functions(HashTable ** names)
{
TSRMLS_FETCH();
- if (BG(user_shutdown_function_names))
+ if (*names){
zend_try {
- zend_hash_apply(BG(user_shutdown_function_names),
(apply_func_t) user_shutdown_function_call TSRMLS_CC);
+ zend_hash_apply(*names, (apply_func_t)
+user_shutdown_function_call TSRMLS_CC);
memcpy(EG(bailout), orig_bailout, sizeof(jmp_buf));
- zend_hash_destroy(BG(user_shutdown_function_names));
- efree(BG(user_shutdown_function_names));
+ zend_hash_destroy(*names);
+ efree(*names);
+ *names = NULL;
}
zend_end_try();
+ }
}
-/* {{{ proto void register_shutdown_function(string function_name)
- Register a user-level function to be called on request termination */
-PHP_FUNCTION(register_shutdown_function)
+PHPAPI void register_shutdown_function_entry(HashTable ** names, int ht, zval *
+return_value)
{
php_shutdown_function_entry shutdown_function_entry;
int i;
- shutdown_function_entry.arg_count = ZEND_NUM_ARGS();
-
- if (shutdown_function_entry.arg_count 1) {
- WRONG_PARAM_COUNT;
- }
+ shutdown_function_entry.arg_count = (ht);
shutdown_function_entry.arguments = (pval **) emalloc(sizeof(pval *)
*shutdown_function_entry.arg_count);
@@ -2118,14 +2115,26 @@
RETURN_FALSE;
}
if (!BG(user_shutdown_function_names)) {
- ALLOC_HASHTABLE(BG(user_shutdown_function_names));
- zend_hash_init(BG(user_shutdown_function_names), 0, NULL, (void
(*)(void *)) user_shutdown_function_dtor, 0);
+ ALLOC_HASHTABLE(*names);
+ zend_hash_init(*names, 0, NULL, (void (*)(void *))
+user_shutdown_function_dtor, 0);
}
for (i = 0; i shutdown_function_entry.arg_count; i++) {
shutdown_function_entry.arguments[i]-refcount++;
}
- zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
+ zend_hash_next_index_insert(*names, shutdown_function_entry,
+sizeof(php_shutdown_function_entry), NULL);
+ RETURN_TRUE;
+}
+
+/* {{{ proto void register_shutdown_function(string function_name)
+ Register a user-level function to be called on request termination */
+PHP_FUNCTION(register_shutdown_function)
+{
+ if (ZEND_NUM_ARGS() 1) {
+ WRONG_PARAM_COUNT;
+ }
+
+ register_shutdown_function_entry(BG(user_shutdown_function_names), ht,
+return_value);
}
/* }}} */
Index: php4/ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -b -r1.109 basic_functions.h
--- php4/ext/standard/basic_functions.h 5 Nov 2002 06:05:48 - 1.109
+++ php4/ext/standard/basic_functions.h 7 Jan 2003 21:00:30 -
@@ -74,6 +74,8 @@
PHP_FUNCTION(highlight_string);
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
[PHP-DEV] apache_register_shutdown_functions
This patch should remove all of the concerns about my previous patches.
You'll notice that there has been no extension to SAPI, and no explicit
closing of the socket. Instead I've returned the Apache SAPI module to its
previous execution code path. The only modification is that the
shutdown_functions are now executed in php_module_main instead of calling
php_request_shutdown which is called as a cleanup function. This retains
the functionality of the existing register_shutdown_function command. An
additional abstraction of the register_shutdown_function procedure allowed
me to minimize the amount of repeated code, and call different types of
shutdown functions. An additional test within php_request_shutdown allows
shutdown_functions on other platforms to operate as in previous versions
without requiring changes to any code.
PHP implementations using mod_php4 on Apache web servers should see an
improvement of speed over the initial 4.3.0 release as the PHP cleanup phase
happens after the http request is terminated.
Please review and send me any comments.
Joseph
P.S. As I have an immediate need for this functionality, I have written the
patch against the php_4_3_0 tagged version of php4. If approved, I'll
rewrite it for PHP_4_3 and HEAD.
? php4/ext/mysql/.libs
Index: php4/ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -b -r1.543.2.4 basic_functions.c
--- php4/ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ php4/ext/standard/basic_functions.c 7 Jan 2003 21:00:30 -
@@ -1121,6 +1121,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -2085,32 +2086,28 @@
}
}
-void php_call_shutdown_functions(void)
+PHPAPI void php_call_shutdown_functions(HashTable ** names)
{
TSRMLS_FETCH();
- if (BG(user_shutdown_function_names))
+ if (*names){
zend_try {
- zend_hash_apply(BG(user_shutdown_function_names),
(apply_func_t) user_shutdown_function_call TSRMLS_CC);
+ zend_hash_apply(*names, (apply_func_t)
+user_shutdown_function_call TSRMLS_CC);
memcpy(EG(bailout), orig_bailout, sizeof(jmp_buf));
- zend_hash_destroy(BG(user_shutdown_function_names));
- efree(BG(user_shutdown_function_names));
+ zend_hash_destroy(*names);
+ efree(*names);
+ *names = NULL;
}
zend_end_try();
+ }
}
-/* {{{ proto void register_shutdown_function(string function_name)
- Register a user-level function to be called on request termination */
-PHP_FUNCTION(register_shutdown_function)
+PHPAPI void register_shutdown_function_entry(HashTable ** names, int ht, zval *
+return_value)
{
php_shutdown_function_entry shutdown_function_entry;
int i;
- shutdown_function_entry.arg_count = ZEND_NUM_ARGS();
-
- if (shutdown_function_entry.arg_count 1) {
- WRONG_PARAM_COUNT;
- }
+ shutdown_function_entry.arg_count = (ht);
shutdown_function_entry.arguments = (pval **) emalloc(sizeof(pval *)
*shutdown_function_entry.arg_count);
@@ -2118,14 +2115,26 @@
RETURN_FALSE;
}
if (!BG(user_shutdown_function_names)) {
- ALLOC_HASHTABLE(BG(user_shutdown_function_names));
- zend_hash_init(BG(user_shutdown_function_names), 0, NULL, (void
(*)(void *)) user_shutdown_function_dtor, 0);
+ ALLOC_HASHTABLE(*names);
+ zend_hash_init(*names, 0, NULL, (void (*)(void *))
+user_shutdown_function_dtor, 0);
}
for (i = 0; i shutdown_function_entry.arg_count; i++) {
shutdown_function_entry.arguments[i]-refcount++;
}
- zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
+ zend_hash_next_index_insert(*names, shutdown_function_entry,
+sizeof(php_shutdown_function_entry), NULL);
+ RETURN_TRUE;
+}
+
+/* {{{ proto void register_shutdown_function(string function_name)
+ Register a user-level function to be called on request termination */
+PHP_FUNCTION(register_shutdown_function)
+{
+ if (ZEND_NUM_ARGS() 1) {
+ WRONG_PARAM_COUNT;
+ }
+
+ register_shutdown_function_entry(BG(user_shutdown_function_names), ht,
+return_value);
}
/* }}} */
Index: php4/ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -b -r1.109 basic_functions.h
---
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
Well, according to my highly technical methods of deduction (fprintf(stderr, Inside sapi_shutdown);) sapi_shutdown is never called when serving a PHP request when served using mod4_php under Apache. This is because the shutdown_wrapper never gets initialized as a cleanup function. This because the php_init_handler is never called, and this happens for some reason undivinable by me. Perhaps it should be used, and we should execute regular shutdown functions there, and proceed to use php_request_shutdown in the way it was used prior to php 4.1.x i.e. after the connection has closed (on apache anyway) and while PHP is still in memory. We'll get the added benefit of (on Apache systems anyway) a significant performance gain as the cleanup phase happens without the client having to wait for it. Here is my vision based on my understanding of the inner workings of PHP. There are at least four types of shutdown functions in PHP (not including extensions): PHP space (identified by the use of register_shutdown_function) module_shutdown (called when a module is to clean up after itself) sapi_shutdown (not used under many sapi implementations) php_shutdown there may also be zend and tsrm shutdown functions. php_shutdown seems to always be a call to shutdown wheras the remainder are called when shutdown occurs. Thus the cleanup/shutdown routines should be called in this order: main init load and run PHP script call sapi_shutdown which calls module_shutdown on all used modules and then executes register_shutdown_functions and then calls php_request_shutdown in a server specific manner (in apache as a cleanup_function after the http communication has terminated) which (under platforms that support it) executes register_offline_functions before cleaning up PHP and freeing memory. SAPI was developed for abstracting the server, but it seems that instead it has been worked around rather than extended for the individual servers. I speak in generalizations, but that's what it looks like. In my book, all php internal functions should be called through the appropriate SAPI functions, which are called by a main function for each sapi implementation. There is too much deviation from this, thereby crippling SAPI. Either use it or cut it out completly. These changes are too large for a minor version release, i.e. 4.3.1, but perhaps for 4.4/5.0? I'd be willing to put some time into reworking the SAPI system. -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 31, 2002 4:21 AM To: Joseph Tate Cc: Php-Dev List; Jason Priebe Subject: RE: [PATCH]apache_register_shutdown_function final version As you can see in bug #15209, the change that introduced this problem was that we started calling php_request_shutdown() in apache_module_main(), prior to calling it from php_apache_request_shutdown(). So, the place to put it is clearly php_apache_request_shutdown(), where it used to be called before. The problem is by the time you would get to php_apache_request_shutdown(), the per-request memory manager is already deactivated, so any emalloc()'d memory you may have is already freed. I'm not sure how to tackle this in a server independent way... Zeev At 21:55 30/12/2002, Joseph Tate wrote: That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 1:57 PM Subject: RE: [PATCH]apache_register_shutdown_function final version Try looking at php_apache_request_shutdown() in mod_php4.c. It's our pool destructor. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/apache2filter php_apache.h sapi_apache2.c
I think you (Sascha) need to provide a proper example of how to do it properly. It's insufficient to just say Don't do that. At least point to a place in the code where it is done properly. These changes are needed by the developer, and the developer will use them whether they're in the codebase or not (I've been using a custom build of PHP for longer than I can remember because my patches don't seem to be acceptable for inclusion into the php code base). If unacceptable, then direct the willing developer in the proper fashion, I'm sure they'll be happy to receive direction to lighten their load. Don't spill wine is not proper direction. This is also a somewhat hypocritical position since similar changes have been done for Win32 compatibility all over the code base. As far as spilling wine, it won't be the first time, nor the last. Joseph Who'd still like his register_shutdown_function patch approved, or at least some direction on how to do it properly. -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 2:25 PM Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/apache2filter php_apache.h sapi_apache2.c I need to say it again. These modifications are *extremely* ugly. It's like spilling a glass of wine over important documents. You won't be able to remove the spilled substance without expensive labor. These modifications lack proper factoring. They repeat the same kind of change all over our code base. Instead of hiding some of netware's properties behind appropiate macros and typedefs, you duplicate existing code in a slightly changed manner all over the place. What do you guys think about this? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Typo in sapi/apache/php_apache.c
Here's a patch. It's in both the 4.3 and head branches. I don't have
sufficient karma to apply the patch.
--- php4/sapi/apache/php_apache.c
+++ php4/sapi/apache/php_apache.c
@@ -115,7 +117,7 @@
ap_child_terminate( ((request_rec *)SG(server_context)) );
RETURN_TRUE;
} else { /* tell them to get lost! */
- php_error_docref(NULL TSRMLS_CC, E_WARNING, apache.child_terminate
is disabled);
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, apache_child_terminate
is disabled);
RETURN_FALSE;
}
#else
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH]apache_register_shutdown_function final version
As a reminder, this replaces the register_shutdown_function functionality
removed in 4.1.x as described at http://bugs.php.net/15209. I've made my
final adjustments to the patch. Please review and commit both to HEAD and
PHP_4_3. I received no response from the SAPI guru's, so I went ahead and
added the sapi_close function to all SAPI modules, initializing it to NULL.
It's not implemented for anything but apache 1.3. Implementing for Apache2
is not a big deal, just call ap_lingering_close from within sapi_close.
With the addition of sapi_close, it should be possible to add the
functionality of apache_register_shutdown_function to every platform
implementing the sapi_close method.
Also, those on non-Apache systems, please test to make sure that this does
not break your builds.
Thanks,
Joseph
[EMAIL PROTECTED]
?php
function shutdown()
{
sleep(3);
print(Shutdown function.\n);
}
function offline()
{
$i = 0;
$out = fopen('/tmp/shutdown_test.out',a+);
for($i = 0; $i 6; $i++)
{
sleep(3);
fputs($out, sleeping\n);
}
fclose($out);
}
apache_register_shutdown_function(offline);
register_shutdown_function(shutdown);
echo This is the end.br\n;
?
? ext/mysql/.libs
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -r1.543.2.4 basic_functions.c
--- ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ ext/standard/basic_functions.c 30 Dec 2002 16:56:02 -
@@ -107,11 +107,6 @@
{3, BYREF_FORCE, BYREF_FORCE, BYREF_FORCE};
-typedef struct _php_shutdown_function_entry {
- zval **arguments;
- int arg_count;
-} php_shutdown_function_entry;
-
typedef struct _user_tick_function_entry {
zval **arguments;
int arg_count;
@@ -119,7 +114,6 @@
} user_tick_function_entry;
/* some prototypes for local functions */
-static void user_shutdown_function_dtor(php_shutdown_function_entry
*shutdown_function_entry);
static void user_tick_function_dtor(user_tick_function_entry *tick_function_entry);
/* Demo code. Enable only if you need this. */
@@ -1121,6 +1115,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -1986,7 +1981,7 @@
/* }}} */
-void user_shutdown_function_dtor(php_shutdown_function_entry *shutdown_function_entry)
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry)
{
int i;
@@ -2006,7 +2001,7 @@
efree(tick_function_entry-arguments);
}
-static int user_shutdown_function_call(php_shutdown_function_entry
*shutdown_function_entry TSRMLS_DC)
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC)
{
zval retval;
@@ -2128,7 +2123,6 @@
zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
}
/* }}} */
-
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini)
{
Index: ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -r1.109 basic_functions.h
--- ext/standard/basic_functions.h 5 Nov 2002 06:05:48 - 1.109
+++ ext/standard/basic_functions.h 30 Dec 2002 16:56:02 -
@@ -74,6 +74,14 @@
PHP_FUNCTION(highlight_string);
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini);
+typedef struct _php_shutdown_function_entry {
+ zval **arguments;
+ int arg_count;
+} php_shutdown_function_entry;
+
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry);
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC);
+
PHP_FUNCTION(ini_get);
PHP_FUNCTION(ini_get_all);
PHP_FUNCTION(ini_set);
@@ -130,6 +138,7 @@
typedef struct {
HashTable *user_shutdown_function_names;
+ HashTable *user_apache_shutdown_function_names;
HashTable putenv_ht;
zval *strtok_zval;
char *strtok_string;
Index: main/SAPI.c
===
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision 1.155.2.2
diff -u -r1.155.2.2 SAPI.c
--- main/SAPI.c 5 Dec 2002 22:15:00 - 1.155.2.2
+++ main/SAPI.c 30 Dec 2002 16:56:04 -
@@ -348,6 +348,15 @@
SG(sapi_headers).http_status_line = NULL;
}
}
+
+/* Close the client connection, but do not terminate execution */
+SAPI_API void sapi_close(TSRMLS_D)
+{
+
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
There probably is a better way to do it. I just haven't been able to figure it out. Most Apache modules wait until the logging stage to execute offline code, but it doesn't seem that at that stage PHP code is still in memory. Thus there doesn't seem to be a satisfactory way to do this. As for explicitly closing the connection, I call flush before I do that, and everything that PHP cares about has been done, except for garbage_collecting and unloading itself. Apache goes ahead and cleans up everything else after the logging stage. I haven't tried explicitly with a Connection-Type: Keep-Alive, but I don't think it will cause browsers to crash. I've tested with IE 6x and Mozilla 1.2.1. My implementation was based on code existing in the apache sources (just not externally available in Apache 1.3.x) lingering_close and much discussion on the Apache-Modules mailing list. If you can point me to a place in PHP land where the Apache process has closed the connection, and the script is still in memory, I'll be happy to make it neater, but in my search (I spent a day or so looking for such a place) I couldn't find anything. Another interesting thing to note is that the Patch that worked with 4.1.x to restore the functionality doesn't work with 4.2 or 4.3, so something has changed so that all resource pool cleanup is happening before the connection is closed rather than after, causing PHP to appear slower than it needs to. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 12:55 PM That's a bit of an odd way to implement it - are you sure closing the link explicitly at that point won't interfere with anything? In 4.1 (or whatever the last version it worked like that was), it was taking advantage of the fact PHP's resource pool was being destroyed after the link was already closed. It sounds a bit risky to me to close the link explicitly at this point, even though I'm not currently aware of any immediate problem this may cause (maybe it would ruin keep-alive?) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 1:57 PM Subject: RE: [PATCH]apache_register_shutdown_function final version Try looking at php_apache_request_shutdown() in mod_php4.c. It's our pool destructor. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
Upon further inspection, it is clear that shutdown_memory_manager is called before php_apache_request_shutdown. This, it seems, hails back from the change that caused cleanup to happen before the connection closed, which may or may not be related to the memory management changes. This causes the Zend engine to deallocate all my nice pointers. php_apache_request_shutdown is run as an apache cleanup routine. This is good design, but in main.c in php_request_shutdown, the PHP code as it exists when the process is running is destroyed. This long before the connection is shut down, and in turn long before php_apache_request_shutdown is run. Thus any attempt to move php_call_shutdown_functions any lower in the execution order of php_request_shutdown results in a segmentation fault. This was what I did originally to test for an execution location where the connection was closed but PHP was still intact. It seems, as I suspected, that there is no place where the connection is closed and PHP code still exists. Back to the solution proposed, I've put a test around the sapi_close call which means that it will only be called if there are registered apache shutdown functions. Will this placate you? It will thus only break keep-alive if there are offline functions to be run. If this is still unacceptable, the php_request_shutdown may need to be redesigned, and thus, I fear, all of SAPI. Joseph -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 2:55 PM Subject: [PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] apache_register_shutdown_function part 2, Now with test script.
I've moved most of the code out of the ext/standard directory and into the
sapi/apache directory. In order to do that I had to make a few of the local
functions in basic_functions.c non-local. See patch for details. The patch
is a complete patch of all my changes and can be applied to a fresh checkout
of PHP_4_3.
I still need someone to tell me how to #ifdef based on the presence of
the --with-apxs configure flag. Also will I need to make modifications to
the other SAPI modules because of the changes to SAPI.c and SAPI.h? There
are a few more changes to be made so that the connection is guaranteed to be
closed down cleanly.
Joseph
? ext/mysql/.libs
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -b -r1.543.2.4 basic_functions.c
--- ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ ext/standard/basic_functions.c 27 Dec 2002 22:17:15 -
@@ -107,11 +107,6 @@
{3, BYREF_FORCE, BYREF_FORCE, BYREF_FORCE};
-typedef struct _php_shutdown_function_entry {
- zval **arguments;
- int arg_count;
-} php_shutdown_function_entry;
-
typedef struct _user_tick_function_entry {
zval **arguments;
int arg_count;
@@ -119,7 +114,6 @@
} user_tick_function_entry;
/* some prototypes for local functions */
-static void user_shutdown_function_dtor(php_shutdown_function_entry
*shutdown_function_entry);
static void user_tick_function_dtor(user_tick_function_entry *tick_function_entry);
/* Demo code. Enable only if you need this. */
@@ -1121,6 +1115,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -1986,7 +1981,7 @@
/* }}} */
-void user_shutdown_function_dtor(php_shutdown_function_entry *shutdown_function_entry)
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry)
{
int i;
@@ -2006,7 +2001,7 @@
efree(tick_function_entry-arguments);
}
-static int user_shutdown_function_call(php_shutdown_function_entry
*shutdown_function_entry TSRMLS_DC)
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC)
{
zval retval;
@@ -2128,7 +2123,6 @@
zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
}
/* }}} */
-
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini)
{
Index: ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -b -r1.109 basic_functions.h
--- ext/standard/basic_functions.h 5 Nov 2002 06:05:48 - 1.109
+++ ext/standard/basic_functions.h 27 Dec 2002 22:17:15 -
@@ -74,6 +74,14 @@
PHP_FUNCTION(highlight_string);
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini);
+typedef struct _php_shutdown_function_entry {
+ zval **arguments;
+ int arg_count;
+} php_shutdown_function_entry;
+
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry);
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC);
+
PHP_FUNCTION(ini_get);
PHP_FUNCTION(ini_get_all);
PHP_FUNCTION(ini_set);
@@ -130,6 +138,7 @@
typedef struct {
HashTable *user_shutdown_function_names;
+ HashTable *user_apache_shutdown_function_names;
HashTable putenv_ht;
zval *strtok_zval;
char *strtok_string;
Index: main/SAPI.c
===
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision 1.155.2.2
diff -u -b -r1.155.2.2 SAPI.c
--- main/SAPI.c 5 Dec 2002 22:15:00 - 1.155.2.2
+++ main/SAPI.c 27 Dec 2002 22:17:15 -
@@ -348,6 +348,14 @@
SG(sapi_headers).http_status_line = NULL;
}
}
+
+SAPI_API void sapi_close(TSRMLS_D)
+{
+ if(sapi_module.close) {
+ sapi_module.close(TSRMLS_C);
+ }
+ sapi_flush(TSRMLS_C);
+}
SAPI_API void sapi_deactivate(TSRMLS_D)
{
Index: main/SAPI.h
===
RCS file: /repository/php4/main/SAPI.h,v
retrieving revision 1.87
diff -u -b -r1.87 SAPI.h
--- main/SAPI.h 12 Nov 2002 20:56:47 - 1.87
+++ main/SAPI.h 27 Dec 2002 22:17:15 -
@@ -130,6 +130,7 @@
SAPI_API void sapi_startup(sapi_module_struct *sf);
SAPI_API void sapi_shutdown(void);
+SAPI_API void sapi_close(TSRMLS_D);
SAPI_API void sapi_activate(TSRMLS_D);
SAPI_API void sapi_deactivate(TSRMLS_D);
SAPI_API void
[PHP-DEV] Concerning register_shutdown_function
I've finally figured out a way to add a register_apache_shutdown_function and have it execute after the connection to the client has closed. This will only be available to users of the Apache web server. A patch will be forthcoming. This message is to gear up testers. The patch will be against the latest PHP_4_3 code, though I don't expect it to be in the first release of 4.3 Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Revision 1 of register_apache_shutdown_function patch
The patch is attached. Please test on your system, especially on non-apache
systems. In its present state it will probably break any non-apache build.
There are a few changes to SAPI.c and SAPI.h that should be looked over by
the SAPI developers. I've added a hook for a beast called sapi_close.
Should this have #ifdefs around it, or do we need to add hooks to all the
other SAPI interfaces.
I will move the register_apache_shutdown_function to the
sapi/apache/php_apache.c file so that it is only available to users of the
apache module. However I had to add a HashTable to the php_basic_globals
struct. Should this be #ifdef'd out on non apache systems? What would be
the preferred way to do this? There are a few other places where we'll have
to do the same thing.
With the SAPI extension, register_apache_shutdown_function could also be
implemented on other web servers/calling methods; If anyone cares to do so
later on.
Joseph
? ext/mysql/.libs
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -r1.543.2.4 basic_functions.c
--- ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ ext/standard/basic_functions.c 26 Dec 2002 17:02:41 -
@@ -552,6 +552,7 @@
PHP_FE(print_r,
NULL)
PHP_FE(register_shutdown_function,
NULL)
+ PHP_FE(register_apache_shutdown_function,
+ NULL)
PHP_FE(register_tick_function,
NULL)
PHP_FE(unregister_tick_function,
NULL)
@@ -1121,6 +1122,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -2129,6 +2131,49 @@
}
/* }}} */
+void php_call_apache_shutdown_functions(void)
+{
+ TSRMLS_FETCH();
+
+ if (BG(user_apache_shutdown_function_names))
+ zend_try {
+ zend_hash_apply(BG(user_apache_shutdown_function_names),
+(apply_func_t) user_shutdown_function_call TSRMLS_CC);
+ memcpy(EG(bailout), orig_bailout, sizeof(jmp_buf));
+ zend_hash_destroy(BG(user_apache_shutdown_function_names));
+ efree(BG(user_apache_shutdown_function_names));
+ }
+ zend_end_try();
+}
+
+/* {{{ proto void register_apache_shutdown_function(string function_name)
+ Register a user-level function to be called on request termination */
+PHP_FUNCTION(register_apache_shutdown_function)
+{
+ php_shutdown_function_entry shutdown_function_entry;
+ int i;
+
+ shutdown_function_entry.arg_count = ZEND_NUM_ARGS();
+
+ if (shutdown_function_entry.arg_count 1) {
+ WRONG_PARAM_COUNT;
+ }
+
+ shutdown_function_entry.arguments = (pval **) emalloc(sizeof(pval *)
+*shutdown_function_entry.arg_count);
+
+ if (zend_get_parameters_array(ht, shutdown_function_entry.arg_count,
+shutdown_function_entry.arguments) == FAILURE) {
+ RETURN_FALSE;
+ }
+ if (!BG(user_apache_shutdown_function_names)) {
+ ALLOC_HASHTABLE(BG(user_apache_shutdown_function_names));
+ zend_hash_init(BG(user_apache_shutdown_function_names), 0, NULL, (void
+(*)(void *)) user_shutdown_function_dtor, 0);
+ }
+
+ for (i = 0; i shutdown_function_entry.arg_count; i++) {
+ shutdown_function_entry.arguments[i]-refcount++;
+ }
+ zend_hash_next_index_insert(BG(user_apache_shutdown_function_names),
+shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
+}
+/* }}} */
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini)
{
Index: ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -r1.109 basic_functions.h
--- ext/standard/basic_functions.h 5 Nov 2002 06:05:48 - 1.109
+++ ext/standard/basic_functions.h 26 Dec 2002 17:02:41 -
@@ -70,6 +70,7 @@
PHP_FUNCTION(call_user_method_array);
PHP_FUNCTION(register_shutdown_function);
+PHP_FUNCTION(register_apache_shutdown_function);
PHP_FUNCTION(highlight_file);
PHP_FUNCTION(highlight_string);
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini);
@@ -130,6 +131,7 @@
typedef struct {
HashTable
RE: [PHP-DEV] GIF support
-Original Message- From: Pierre-Alain Joye [mailto:[EMAIL PROTECTED]] On Wed, 20 Nov 2002 14:01:06 +0100 Carsten Gehling [EMAIL PROTECTED] wrote: A question popped into my mind. I know GD doesn't support GIF because of Unisys' license on the LZW compression format. Then how can ImageMagick support it? afaik, it supports uncompressed GIF, which is useless :). PHP bundled GD supports read support for GIF, as far as you do not need to output GIF images (mobiles) try to use png or others formats instead. It'll support LZW compression if you recompile it and the tiff libraries. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Where is the http connection shut down?
I'm trying to add my new function, register_offline_function, and have it
pretty much finished, but need a few pointers.
The php_request_function in main/main.c is where I'm working currently.
I've set up the function very similarly to the current
register_shutdown_function mechanism, and I've changed the
php_request_shutdown function to:
void php_request_shutdown(void *dummy)
{
TSRMLS_FETCH();
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1
) TSRMLS_CC);
} zend_end_try();
zend_try {
sapi_send_headers(TSRMLS_C);
} zend_end_try();
if (PG(modules_activated)) zend_try {
php_call_shutdown_functions();
} zend_end_try();
if (PG(modules_activated)) {
zend_deactivate_modules(TSRMLS_C);
}
/* Need to call something to close the http connection. */
if (PG(modules_activated)) zend_try {
fprintf(stderr, Calling Offline Functions.\n);
php_call_offline_functions();
} zend_end_try();
zend_try {
int i;
for (i=0; iNUM_TRACK_VARS; i++) {
if (PG(http_globals)[i]) {
zval_ptr_dtor(PG(http_globals)[i]);
}
}
} zend_end_try();
zend_deactivate(TSRMLS_C);
zend_try {
sapi_deactivate(TSRMLS_C);
} zend_end_try();
zend_try {
shutdown_memory_manager(CG(unclean_shutdown), 0 TSRMLS_CC);
} zend_end_try();
zend_try {
zend_unset_timeout(TSRMLS_C);
} zend_end_try();
}
I've tried moving the php_call_offline_functions() further down the
execution chain, but I can't put it after the zval_ptr_dtor loop, or move
the zend_deactivate() call up to be before it because these calls toast the
hashtable that stores the functions. What I'd really like to do is extract
the call that shuts down the http connection from the shutdown procedure and
move it into main.c if possible. Problem is that I can't figure out where
that happens. Is there a better way to do this?
Joseph
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [4.3] Current critical bugs
Throw me a bone then. What is the suggested way to offer php developers the opportunity to run code after the connection has been closed? Even if it only works under Apache on Linux? Also if the 4.1.0 behavior is the correct behavior, why is the function still documented as the 4.0.x behavior? I'll admit that the company I work for is probably the only one using this function, but we depend on it. We do heavy image processing work, using image magick, called from clients using wireless networks, where it hurts us to keep connections open for long periods of time. If we can't fork some processing to the background, our users think our app is slow, and we lose sales. It's that simple. Correct behavior or not, we need the functionality. My patch, I hope, will be ready by the end of the week. Adding a parameter to the register_shutdown_function will not be possible, since the function was changed a while back to allow users to specify arguments to the function being registered. Instead a second function will be created: register_offline_function offering the 4.0.x behavior. Joseph Zeev Suraski wrote: Summary: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x URL: http://bugs.php.net/bug.php?id=15209 I stated my stand on this, I believe that the 4.1.0 behavior is the more correct one. I have to go now, but I'll look at the rest of relevant bugs later today. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [4.3] Current critical bugs
Thanks. I appreciate the response. Joseph Zeev Suraski wrote: At 21:14 15/10/2002, Joseph Tate wrote: Throw me a bone then. What is the suggested way to offer php developers the opportunity to run code after the connection has been closed? I think I mentioned this as well; IMHO, if we want to create the ability for users under Apache/UNIX to run stuff after the connection is closed, we should add a dedicated function for it, it shouldn't be overloaded to register_shutdown_function(). It can be apache_register_shutdown_function() or something like that, so that it would be clear it takes advantage of platform dependent functionality. Even if it only works under Apache on Linux? Also if the 4.1.0 behavior is the correct behavior, why is the function still documented as the 4.0.x behavior? Because those who document the code and those who develop it are usually not the same people :) I'll admit that the company I work for is probably the only one using this function, but we depend on it. We do heavy image processing work, using image magick, called from clients using wireless networks, where it hurts us to keep connections open for long periods of time. If we can't fork some processing to the background, our users think our app is slow, and we lose sales. It's that simple. Correct behavior or not, we need the functionality. My patch, I hope, will be ready by the end of the week. Adding a parameter to the register_shutdown_function will not be possible, since the function was changed a while back to allow users to specify arguments to the function being registered. Instead a second function will be created: register_offline_function offering the 4.0.x behavior. I have no objection to adding the Apache specific equivalent to 4.3. As a matter of fact, if it solves a problem - I'm quite for it. I hope this bone is meaty enough :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Bug 15209 fix--register_shutdown_function(string function, bool exit)
Bug 15209 has been open since 24 Jan, 2002. Simply put, the behavior of the register_shutdown_function in th 4.0.x series was to close the connection to the client then run the registered functions. At the release of 4.1.0, this behavior was changed, breaking BC, and offering no alternative functionality, to run the registered functions before closing the connection with the client. Since that time my company has been using a patched version of PHP to develop its product stifling our adoption of later releases of php, even version 4.2.x releases. This has in turn reduced my ability to contribute to the php code base. It should be noted that a patch to solve the problem has been in existence since day one. I propose that we take following action: that we add a second parameter to the register_shutdown_function named exit which allows the user to replace the functionality once available in 4.0.x (perhaps earlier), since documented at http://www.php.net/manual/en/function.register-shutdown-function.php as The registered shutdown functions are called after the request has been completed (including sending any output buffers), so it is not possible to send output to the browser using echo() or print(), or retrieve the contents of any output buffers using ob_get_contents(). and removed from 4.1.x and 4.2.x (which means the documentation is messed up). This will allow applications that do a lot of behind the scenes processing, i.e. graphics rendering or complex data analyses, to be built using php instead of cgi or some other alternative. I'll be happy to provide a patch for this if I can be reasonably sure that it will be committed. I hope that this issue can be resolved before the release of 4.3.0. Joseph Tate -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Development FAQ?
There are a few ways to do it. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm l/_atl_using_debugbreak.asp Add _asm int 3; where you want to break. Use a dialog to pause execution until you can attach the debugger to it: #ifdef _DEBUG char szMessage [256]; wsprintf (szMessage, Please attach a debbuger to the process 0x%X (%s) and click OK, GetCurrentProcessId(), argv[0]); MessageBox(NULL, szMessage, CGI Debug Time!, MB_OK|MB_SERVICE_NOTIFICATION); #endif Or add a registry key (only works with dlls). I can't find it in the MSDN right now, but it's set up in \\HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\exe or dll filename then just add a DWORD type entry named BreakOnDllLoad 1 breaks 0 does not break when the dll is loaded. Basically debugging is based on your ability to stop exection or attach to a running process. Hopefully I've given you a few good starting places. -Original Message- From: Jon [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 6:39 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Development FAQ? Hello, Is there a PHP Dev FAQ somewhere? If not, then I would like to ask your help. I have PHP set up and compiling on my Win2k box. My question is, how do I debug php.exe while it's running as a CGI application? Can you give me some tips on how to set up my environment for debugging? Thanks, Jon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Win32 project files
Looks ok to me. -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 4:41 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] [PATCH] Win32 project files A while ago I started working on main/config.w32.h beeing generated from main/config.w32.h.in. The benefit of this is to allow for a Win32 build configuration that doesn't conflict with CVS versions, since only config.w32.h.in is only known to the repository. Anyways, my earlier version of this patch didn't work and config.w32.h was always overwritten during the build, rendering the mechanism useless. Attached is a patch that fixes this mess. I tested it, hopefully well enough, but would like a fresh pair of eyes to look over it before I commit it. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Windows builds and ftp.c
I believe that the consensus with warnings on the windows builds is that we don't care. We're not going to cast where it isn't necessary. So you might want to revert your last patch. Joseph -Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 5:21 PM To: PHP Development Mailing list Subject: [PHP-DEV] Windows builds and ftp.c Warnings in the Windows FTP builds, which may be of concern (or may not be): ftp.c(650) : warning C4018 : '!=' signed/unsigned mismatch ftp.c(1565) : warning C4018 : '!=' signed/unsigned mismatch --- Dan Kalowsky A little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED] Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3 and PHP 5
And a couple more things. Adding to the ever expanding list... On Wed, 21 Aug 2002, Sterling Hughes wrote: Hi all, Following on from the recent debug_backtrace discussion, and the discussion about just what we are releasing next and so on, I'd just thought I would make a couple of comments about PHP 4.3 and about what I think (IMHO) should be the goals of PHP 5. I'm currently reviewing the streams code, to make sure that the API is good enough for a release: there are a couple of things that I want to tidy up ready for PHP 4.3: o Add a set-blocking-flag method to the generic stream operations, So that non-blocking IO can be enabled on any stream that it makes sense to do so. (IIRC, there is a bug in the DB, or this deficiency was mentioned on the list). o Tidy up persistent streams support. (I need some help from someone that really knows what they are doing here). This is important, because I'm not sure that persistent sockets (pfsockopen) are actually working in HEAD ATM. o Implement a filter API, so that filters can be stacked over a stream. I've mentioned this before; it will be useful to stack things like base64, charset conversion, zlib/bzip compression and crypto over a stream - potentially multiple filters. I don't think that this will take too long to implement (perhaps by the weekend). o Implement stat() and readdir() for ftp. I think http will be too hard to achieve in time for 4.3. PHP 5 - Zeev raised the issue of figuring out what we want to be in PHP 5. Well, I can't think of (m)any fancy new features for PHP 5 that we haven't already got in HEAD, but to get the ball rolling, this is my take on how PHP 5 could/should look: Current HEAD, stabilized. This includes things like the new build system, streams, enhancements to post/file uploading, domxml and so on. ZE2, feature complete. (New OO, better rpc/com/java, try/catch, delegation, etc. etc.) To me, that sounds really pretty good. Yes, it's just HEAD with ZE2, but I think it's almost what will be PHP 5. A couple of additions that would make it more attractive: o PEAR/PECL CA fully established. I know that we are aiming to get this off the ground for PHP 4.3, but I'm sure we can improve it for PHP 5. o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. o Finish off Harald's RPC extension, which should provide Seemless web services. Move Brad's extension into PEAR/PECL, for those people who need to use soap in a manly, yet sexy way. o We really need some people to look at PHP's XML support. Yeah, currently, it kinda-sorta works, however, we can really do it better. I suggest using the DOMXML extension as a base (so much work has been done already). Test strongly, Add full LibXML support, standardize the API to DOM's api, and bundle libxml libxslt with PHP version 5 (removing expat bundling). o See if we can get cURL bundled for PHPv5. o In that vein, get a proper standardized bundling scheme setup, that makes it easy to bundle/unbundle software with PHP. o Update ODBC to v 3.7 support. The current v2 support just doesn't cut it anymore with users wanting to use IMAGE, TEXT, NTEXT, and other various large data field types, and unicode. I started this, but my resource books were ummm... acquired by another and never returned. o Decide if we are or are not going to support the iPlanet system. If we are, it needs to be drastically fixed, if we're not we need to drop it. Really. Look at the bug reports. o Rewrite the ISAPI IIS interface. Gasp. From the ground up, or find some other way to fix bug #15333. The work arounds listed in the bug report are not acceptable in production systems, just as temporary stop-gap methods for developing new applications until a true fix is found. o Fix register_shutdown_function to work as it did with 4.1, or add a seperate function to add this functionality. And then get it to work on windows. See bug #15209. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] HELP HELP HELP
You have to declare the variables as globals, or set register_globals to On in you php.ini file. In any case. Please direct all newbie questions on developing with php to php-general. php-dev is for development of php itself. Joseph -Original Message- From: JJ [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 10:59 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] HELP HELP HELP Hey kinda newbie question here. I am running apache 1.3.6 (tryed with 2 for that matter) and I can't run php scripts properly, the scripts are interpreted fine but I can't pass any vars from an html form, they just come out empty. I tried with GET and POST with no luck. All seems to be fine in php.ini and in http.conf I am running php as cgi. any ideas? Help would be greatly appreciated. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP (Tutorial) Documentation
www.php.net Please ask questions like these on the php-general list. This list is for the development of PHP, not with PHP. -Original Message- From: Joshua Abbott [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 5:17 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP (Tutorial) Documentation Importance: High Hello, Might anyone know of a complete source on the internet for PHP Documentation?? J Abbott Advanced Web Hosting Control Panel Project [EMAIL PROTECTED] == the Advanced Web Hosting Control Panel Project (Extend your life a little) == -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] how to debug a php extension...
Which platform are you on? Linux? Look for 'How to generate a backtrace' on the php.net website, as David posted. Windows? Limit the number of active server processes to 1, then using MSDEV, attach to the running apache process. (It'll help if both apache and your extension are built in debug mode.) Then make it crash. Debug as you would any windows App. Joseph -Original Message- From: Ron Lange [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 9:47 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] how to debug a php extension... hi, in which way I could debug my extension (builtin, apachemodule)? unfortunately I get segmentation faults of the forked apache proc, and I can only guess where it is. It's in a particular place, where I set up a socket and two fds. I don't use php_streams. Any hints? Regards Ron -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bugpack 13
You can convert back to NTFS, just not for free. The better Disk Management utilities (i.e. Partition Magic) offer this functionality. -Original Message- From: Tit Black Petric [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 6:37 AM To: Magnus M; Michael Dransfield Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Bugpack 13 (warning) note that you cannot convert a partition back to fat32 in case you might want to. meaning, when youre on nfs you stay on nfs.. unless you reinstall. other than that nfs is for the better imo :) - Original Message - From: Magnus M [EMAIL PROTECTED] To: Michael Dransfield [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 12:20 PM Subject: Re: [PHP-DEV] Bugpack 13 On Tue, 02 Jul 2002 23:26:20 +0100 Michael Dransfield [EMAIL PROTECTED] wrote: i can help, but do you actually need NTFS? for some reason my pc was loaded with fat32 and win2k :-/ You can convert to ntfs with convert if you want it to be NTFS.. convert /FS:ntfs c: or something like that =) Try convert /? (snip) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DOMXML Function consistency
A bug report or two have been made regarding function names in attribute nodes. Taking a look, nodes have the following access functions: node_name node_type node_value etc. However attribute nodes have the following access functions: name value specified I am thinking that to make it more consistent, we should change the attribute functions to attr_name or node_name attr_value or node_value attr_specified or node_specified I'd vote for the latter series since the programmer already knows they're attributes. Renaming will reduce the WTF factor. We can leave the aliases to the old functions for a while to maintain BC. WISH: I wish there was a Zend Function for marking a function alias as deprecated, I.e. so that a warning message is displayed if the function is used after being marked deprecated. A way to display the replacement function in the warning message would be nice too. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
How much of C has been reused, and reused and reused again? There is no oo in stdlib. -Original Message- Code reusability is a psychological issue. You can reuse code in PHP 4, and it'll be even better in 5 - PEAR is a clear demonstration of this. Whether people actually end up reusing code depends on the way they code, very little does it depend on the language. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP in the future
Emacs!!! XEmacs!!! Emacs!!! XEmacs!!! Now seriosly kids. My opinion is that none of the modifications that have been discussed actually change the language into something better. Everything that you can do with the proposed modification, you can do without. Sure multiple inheritance makes this easier, but opens up cans of worms only solved in hundreds of development iterations. Sure typing (even optionally) keeps you from shooting yourself in the foot, or at least from hurting yourself too bad while doing it, but it also makes it just a little more difficult to program. Operator overloading makes it so that you don't have to type so much, but adds no functionality to the language (It bugged me too until I learned Java, and what is referred to as operator hell). Case Sensitivity just makes it so that if you can't remember if it's myFunction or MyFunction or myfunction or MYFunction or myFUNCTION (you get the picture) you have to go and look it up before your script will run. I propose that all discussion of adding to or changing the language itself be suspended until such time as it can be demonstrated that PHP can be maintained in and of itself in its current state, and this by use of the following milestones: * A complete regression test suite that is maintained concurrently with the development effort. Each bug that is fixed receives a test case to be checked with make test). A lot of extensions don't even have test suites. And last time I ran make test, the results were so useless and non-representative that I no longer try to run it. (Granted that was a couple of months ago.) * Nightly snapshot builds on the big three: Linux, Windows, and Solaris. I/My company can donate cycles to this task on some pretty nice machines if needed. * Complete core compatibility on all *NIX platforms as well as Windows. If a function cannot be implemented on any given platform, it should be deprecated/removed from the core. Register_Shutdown_function comes to mind. * Average new daily valid bug reports should be less than 10. Average daily open bug reports should be no more than 100. I've got ideas on how to help make this happen, and will release them to any who asks. * Extensions that do not compile and function on every platform should be removed to some non-core location. If it's not portable, then it's not PHP. * Complete documentation on every extension and function and structure and operator and nuance and etc of the PHP core. If and only if all of the above conditions are met can we think about extending/tweaking the language. If we do, any more than has already been done, before we have that solid base, PHP is going to be so top heavy, and so bottom weak that it will collapse. Joseph P.S. RANT Abstract=Why my company, and as a result, I won't be using PHP anymore, and why this discussion won't change that outcome.My work with php has come about because we decided that php would be the best platform in which to create a web application. We had experience with mod_perl, CGI, as well as Java, and by far the easiest to use and the quickest to develop in is PHP. The entire application was written procedurally. Only at the very end did I create a class, and that because I didn't feel like passing 6 or 7 parameters when I made a function call and I was being lazy. I never was upset because php didn't have this language feature or that OO nicety. What did get me was the non-portability of the supposedly portable Scripting Language, but there are open bugs on all of those issues. Nobody's even tried to touch those bugs, but they're open. Now, because of the gotchas we had with the first app, the next web application will be done in C/C++ because it turns out that PHP is not as portable as we were led to believe. This feature or that feature or the other may or may not be available on a given platform. We all have more important things to do: I'd really like the Register_Shutdown_function bug that's been around since the release of 4.1 to be fixed. Then while you're at it, get it working on Windows. That takes precedence over ANY language extensions in my mind, as do all of the open bugs in the bugs database. On a different vein: have you ever tried selling a PHP application to a customer? How about a customer that only has Windows/IIS in house and doesn't feel comfortable about bringing in a *NIX/Apache server in to deploy your product? They care not about whether it is case sensitive, or how Object Oriented it is. They want it to run, run well, and run without crashing. As a general rule, PHP/IIS is experimental at best, but nobody seems to want or to be able to work on it. So we lose sales... I've tried, but failed because I can't understand the Zend engine. What do those lost sales translate to? You guessed it, our next application will not be developed in PHP, and our current app probably will be rewritten in C. And I won't be able to contribute anymore. Such is
RE: [PHP-DEV] changed behavior of shutdown-registered function in 4.0.x-4.1.x (conn. handling)
Please do not cross post. The register_shutdown_function bug has been open for quite some time: See bug #15209 at http://bugs.php.net/bug.php?id=15209. I work with the original poster, and have access to his patch that seems to fix the problem. I'm working on it today, and hopefully will have a fix soon. Joseph -Original Message- From: Tamas Arpad [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 11:58 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PHP-DEV] changed behavior of shutdown-registered function in 4.0.x-4.1.x (conn. handling) Hi, I use register_shutdown_function to regenerate my content-cache's data after the old page were sent. In 4.0.6 there was no problem with it, the connection was closed after the normal script is finished, and before the shutdown_registered function is started (which does the real work). So I could use it for gaining a fake speed in delivering pages, and it really made our system faster because only one process can regenerate the page in a time, the others simply return the old content. But unfortunatelly this doesn't work since 4.1.x, because after the normal script finishes it still holds the line. It doesn't close the connection, so the browser is still waiting for data (and the http process is being held too). Is there any php.ini setting or switch for configure that I can use for turning off this behavior? Or is there any other reason why it works this way for me? If I copy the old (4.0.6) php module over the new one (4.1.1) it works fine. For the dev list: Is there any real reason for this way of connection handling, or it's just a side-effect of some other featuer? Thanks for your help, Arpi p.s.:sorry for mailing this to the dev list too, but I don't know where can I find somebody who can help -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bundling libxml2 / bundling locations
TONGUE_IN_CHEEKReally what we should do is in the configure process, if --with-dom is specified and not found on the system, we could call wget, untar, ./configure make, etc. It's the same right? Oh, then we depend on wget being installed./TONGUE_IN_CHEEK What is the status quo? If you install perl on a system, it runs out of the box right? Sure, well so does php, except that expat is required to build php, so it's bundled. Now, when you install a perl module, you also have to install the libraries upon which it depends. That's only fair. It's the accepted status quo. Effort would far better be spent creating an extension dependency tree page that links to the libxml page so that if one wants to install an extension, he or she knows exactly where to go to get the libraries that they depend on. No suprises, no gimmicks. Now on Windows or similar systems, where the average user is not used to system administration (witness the number of codered attacks still going around), we can pack all these dependant binary libraries into the installer. I'm not sure who builds the installer, but I know I could make one in no time flat, and would be willing to do so (and even automate a build process if necessary). -1 on the bundling idea. +1 for choice. +1 for binary bundling on Windows. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:05 AM To: Dan Kalowsky Cc: brad lafountain; PHP Development Mailing list Subject: Re: [PHP-DEV] bundling libxml2 / bundling locations At 11:39 PM 5/30/2002, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I don't see why it's a problem to bundle libxml2 at all. It doesn't have to be in our CVS, we can integrate it into the makedist procedure, provided Brad can automate his trim-down process. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Compile php_zend2 w32 domxml, the 2nd
I think this would be the correct list, but I doubt that anyone has tried to do what you're trying to do. What I would look at first is the list of linked libraries in the project settings. They're probably set to ZE1 settings, and could stand to be updated. Other than that, the standard tricks apply as with all linking errors. The solutions given in the MSDN for link 2019 should give you a clue as to how to fix it. Please keep the list posted as to the steps that you take when you do get it working so that we can make the changes to the project files. If you can't get it working, please post a bug at bugs.php.net. Joseph -Original Message- From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Compile php_zend2 w32 domxml, the 2nd hi again you may haven't noticed yet, but i recently posted a question in here... !--- snip --- hi ng ! i just compiled php with zend2 on win32 using vc7 - after few minor pitfalls it did work out very well. now my problem is that i want to enable domxml extension and therefore wanted to compile it with latest libxml2. compile runs well but the linkage is somehow broken. linker gives error lnk2019 unreferenced external symbol _zend_objects_get_address referenced in function _php_xpath_get_object. (inirectly via macro Z_OBJPROP_P). do i have a chance to compile without errors ? any help and suggestions welcome, thx ilker !--- snip --- i've been following the list now for some hours, and it seems to me that andi and sebastian are heavily working on zendengine2 object management. i do not consider my question as really urgent or important. nevertheless, reading the latest posts (which obviously seem to be cvs commits and comments of you two), i tend to assume that my question is an actual question. ok, i know (or at least can guess) you have better things to do than answering a question of a newbie. however i'd be _really_ glad if you just would give me a hint or would say: hey buddy - wait - it's on the way to work or something similar. a solution would be the greatest anyway. so, _please_, if anybody knows anything about this issue i mentioned above, or even has a solution or hint for me, _please_ reply. i might be in the wrong newsgroup here. if so, please give me an advice where i can post this question accordingly. please excuse my bad english, thank you indeed, ilker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Fix for bug 16888
The following fixes bug 16888 so that Apache and IIS no longer crash on Windows when using the domxml extension with more than 128 nodes. See http://bugs.php.net/bug.php?id=16888 for details. Will the memory leak gurus please have a go at this and let me know what problems arise? Also, please test on non Win platforms to make sure that no functionality is lost. I'll commit it on Tuesday after I get back from vacation. Thanks, Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h...registry configuration
Well, you are correct that the size of the executable is irrelevant, but having different instances of PHP means less shared pages when multiple copies are loaded. There is a definite advantage to having a single httpd binary that is the same for everyone when it comes to runtime memory usage. There is a way around this; well the majority chunk of this problem can be solved by simply making the largest chunk of php into a library, then you have tiny launching executables that live in the various directories, and each similar versioned copy of php uses the same php4.so.4.2.1 library (or similar on Winbloze (10 blue screens too many last night on 2000 and XP)). There will be even more pressure to provide BC, but it will reduce the overall memory footprint. Each executable will have its own heap and stack, but the library will be shared, and its memory will be shared. Someone was talking about making php into a shared library, this is just more incentive to do so. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] config.w32.h
1. I think it's ok. 2. I'd create a batch file that does the renaming, and then set it up to run in a custom build step. You can set those up through the Custom Build tab in the Project settings dialog. Joseph -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 1:20 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] config.w32.h As you may know, I worked a bit on config.w32.h recently. I'd like to rename the file to config.w32.h.in and let MSVC rename config.w32.h.in to config.w32.h, if config.w32.h does not yet exist. Two questions: 1.) Is this okay? 2.) How do I do this? :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Suggestion] Web server line in bug reporting form
I think we should add a dedicated line for the web server type in the bug reporting form. That will cut down on the number of what webserver are you running questions as well as the number of bad assumptions. This should also go into the e-mails sent to the php-bugs list. If this has been suggested before and determined not useful, just ignore this post. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php extensions on windows
Look through the php4/ext directories for project files. Add the project files to the php4ts workspace in VC++, and then compile them. If an extension doesn't have a .dsp file for it, it hasn't been compiled for windows. (Though support for windows is not that hard to add, if all the libraries are available.) Joseph -Original Message- From: Igal Raizman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 10:05 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] php extensions on windows Hello, Can someone point me in the directions of a tutorial or perhaps some info on making PHP extensions on a Windows system ? not on how to code them, but rather on how to compile them on a windows system. Thanks, -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] The PHP Platform
I didn't know that compiling with just domxml gave xslt as well. are you sure of this? --with-dom-xslt and --with-dom-exslt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php installation in XP
The better forum to ask these kinds of questions is on the php-general list. See http://www.php.net/mailing-lists.php for the complete listing. Make sure that you read through the installation guide again before posting though. -Original Message- From: maria [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 8:08 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] php installation in XP Dear Friends, I have installed php in windows XP professional with IIS web server by following the instructions in the manual. But when i run the php test program thru ie it displays HTTP 500 - Internal server error Internet Explorer I had run the 'php -i' in command prompt too. It displays the html tags. So I think the problem is in configuration only. Can anybody help me in locating my error? and also the configurations to be done in php.ini file? and also things to be done in IIS? Thanks in advance. Regards, Maria -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] domxml nightmare and suggestion
I personally could care less about w3c-DOM compliance, as long as I can do everything to the DOM that I need to, and as of 4.2.0, I can. Yes the DOMXML stuff could be cleaned up, or even replaced, but it's functional. It looks like gdome2 is just a wrapper around libxml2 that makes it w3c-Dom complete, so in using that we may be able to make our lives easier (assuming that the project is well maintained). If there was to be an effort to make a w3c-dom compliant extension, then we should make it a separate extension. I don't think that I would work on it though, since everything that I need is already there (plus lots of stuff that I don't need right now). Any deficiencies can be dealt with as they arise, but with the changes that have been made in the last couple of weeks, including the changes that Uwe made this afternoon, I don't think there are many left. Joseph -Original Message- From: Christian Stocker [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 13, 2002 6:42 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] domxml nightmare and suggestion Hi In the last weeks, whenever i read some comments about php and what is bad about it (besides all the good points :) ), domxml seems to be one of the top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Furthermore, to make the task in implementing a full w3c-DOM-API a lot easier, i would suggest, we would use libgome2 (http://phd.cs.unibo.it/gdome2/) as the underlying library. gdome2 is based on libxml2, but provides a W3C-DOM level2 implementation (not like libxml2, which has it's own DOM-implementation). The only disadvantage is, that it needs libglib as well, so we would add another library to the prerequisites for domxml... (BTW, libgdome2 seems to be compiling under Windows as well) Ideas, thoughts, etc? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Addition of PHP_MINOR_VERSION, PHP_MAJOR_VERSION and PHP_RELEASE_VERSION (patch included)
In order to accommodate different operating systems (most notably windows, which likes a Major, Minor, Release, Build release number) who use a different version numbering scheme, I've modified configure.in and the stock main/php_version.h to separate out the Major Minor Release c. from PHP_VERSION. The patch is attached. Would someone with sufficient Karma please commit it. It has no affect on the production of ./php_version.h with configure and does not change the standard PHP_VERSION at all so shouldn't break anything. If you'd like to change the names of the defined variables, feel free. Thanks, Joseph version.patch Description: Binary data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Addition of PHP_MINOR_VERSION, PHP_MAJOR_VERSION and PHP_RELEASE_VERSION (patch included)
Thanks. One day I'll muster up the nerve to ask for Karma. Not yet though. Much power requires much responsibility. -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 11:14 AM To: Joseph Tate Cc: Php-Dev List Subject: Re: [PHP-DEV] Addition of PHP_MINOR_VERSION, PHP_MAJOR_VERSION and PHP_RELEASE_VERSION (patch included) I've applied your patch to HEAD. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch to add version info to php4isapi dll.
If someone would like to apply it, here's a patch to add versioning to the php4isapi.dll file. The necessary files are attached and should go in the same directory as the .dsp project file. Note due to the new partitioned version scheme just inserted today. These files require no modification when version numbers are changed. Index: sapi/isapi/php4isapi.dsp === RCS file: /repository/php4/sapi/isapi/php4isapi.dsp,v retrieving revision 1.16 diff -u -r1.16 php4isapi.dsp --- sapi/isapi/php4isapi.dsp26 Dec 2000 22:15:32 - 1.16 +++ sapi/isapi/php4isapi.dsp11 Apr 2002 16:05:51 - -156,10 +156,18 SOURCE=.\php4isapi.def # End Source File +# Begin Source File + +SOURCE=.\php4isapi.rc +# End Source File # End Group # Begin Group Header Files # PROP Default_Filter h;hpp;hxx;hm;inl # End Group +# Begin Source File + +SOURCE=.\php4isapi.rc2 +# End Source File # End Target # End Project php4isapi.rc2 Description: Binary data php4isapi.rc Description: Binary data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h
What error message are you getting? I don't have VS 98, so I can't really test this. I'll see if I've got a version in my MSDN library, but I doubt it. Joseph -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 12:46 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h Joseph Tate wrote: jtate Thu Apr 11 12:31:24 2002 EDT Added files: /php4/win32 php4dllts.rc php4dllts.rc2 php4ts.rc php4ts.rc2 php4ts_cli.rc php4ts_cli.rc2 resource.h Modified files: /php4/win32 php4dllts.dsp php4ts.dsp php4ts_cli.dsp Log: Added versioning to dll and exe files created under windows. #Note that these do not require modification when the version number changes. #Utilizes the new partitioned version number defines in php_version.h @ Added version info to the dll and exe files created under Windows. (jtate) MS Visual Studio 98 cannot load the workspace. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h
Sorry. I do have vc 98. It's just I've never referred to it as that. I call it VC 6.0. I'm checking it out right now. Should be a pretty quick fix. -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 1:29 PM To: Joseph Tate Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h Joseph Tate wrote: What error message are you getting? I don't have VS 98, so I can't really test this. I'll see if I've got a version in my MSDN library, but I doubt it. Then what version are you testing this with? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h
They're fixed now. Sorry about that. -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 1:48 PM To: Sebastian Bergmann; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h That's what I get for using cygwin's patch (which stripped all the \r's) and not checking before I check in. Updated project files will be in momentarily. Just building to make sure that they still work. Joseph -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h Joseph Tate wrote: What error message are you getting? Forgot to answer that one: 'This makefile was not generated by Developer Studio.' -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h
That's what I get for using cygwin's patch (which stripped all the \r's) and not checking before I check in. Updated project files will be in momentarily. Just building to make sure that they still work. Joseph -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] cvs: php4 /win32 php4dllts.dsp php4dllts.rc php4dllts.rc2 php4ts.dsp php4ts.rc php4ts.rc2 php4ts_cli.dsp php4ts_cli.rc php4ts_cli.rc2 resource.h Joseph Tate wrote: What error message are you getting? Forgot to answer that one: 'This makefile was not generated by Developer Studio.' -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Patch to add version info to php4isapi dll.
Note if after applying this patch the project fails to load, it's because of a \r\n issue. Fix those and the project will load just fine. Joseph -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 12:21 PM To: Php-Dev List Subject: [PHP-DEV] Patch to add version info to php4isapi dll. If someone would like to apply it, here's a patch to add versioning to the php4isapi.dll file. The necessary files are attached and should go in the same directory as the .dsp project file. Note due to the new partitioned version scheme just inserted today. These files require no modification when version numbers are changed. Index: sapi/isapi/php4isapi.dsp === RCS file: /repository/php4/sapi/isapi/php4isapi.dsp,v retrieving revision 1.16 diff -u -r1.16 php4isapi.dsp --- sapi/isapi/php4isapi.dsp26 Dec 2000 22:15:32 - 1.16 +++ sapi/isapi/php4isapi.dsp11 Apr 2002 16:05:51 - @@ -156,10 +156,18 @@ SOURCE=.\php4isapi.def # End Source File +# Begin Source File + +SOURCE=.\php4isapi.rc +# End Source File # End Group # Begin Group Header Files # PROP Default_Filter h;hpp;hxx;hm;inl # End Group +# Begin Source File + +SOURCE=.\php4isapi.rc2 +# End Source File # End Target # End Project -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Request for change of configure.in and main/php_version.h
In order to accommodate different operating systems (most notably windows, which likes a Major, Minor, Release, Build release number) who use a different version numbering scheme, I've modified configure.in and the stock main/php_version.h to separate out the Major Minor Release c. from PHP_VERSION. The patch is attached. Would someone with sufficient Karma please commit it. It has no affect on the production of ./php_version.h with configure and does not change the standard PHP_VERSION at all so shouldn't break anything. If you'd like to change the names of the defined variables, feel free. Thanks, Joseph version.patch Description: Binary data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend questions and bug #15333
http://bugs.php.net/15333 I've narrowed down the problem, but can't seem to get anywhere with it. The state of the server when the problem occurrs: All serviceable threads have been killed or have timed out. A request is received prompting the spawning of a new thread. The new thread then goes through and copies the global_constants_table, but that has been corrupted somewhere causing an access violation when trying to dereference uninitialized memory. This happens every time the server has been idle for ~10 minutes after serving up php pages. Here are my questions that I haven't been able to track down yet. Hopefully someone can save me some time. 1. What code is executed when a thread times out? zend_shutdown never seems to run (or at least my breakpoints there never fire). 2. It appears that global_constants_table is not global nor constant, each thread has a separate copy. Why is this the case? And if it is meant to be, where is the original global_constants_table. What could be modifying it so that it cannot be copied when a new thread is started? 3. Where would be a good place to start to find the answers to the zend questions that I have as I track this down. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] zend questions and bug #15333
zend_strndup is a php implementation. It does not use the strndup function available through MS's library. The problem occurs because a length of 100 or more is passed in, signifying to me that the source of that length has become corrupted or not initialized. I've traced that back to the global_constants_table structure. I no longer get the specific error mentioned in the bug report, but get an error in the same location under the same circumstances. My error looks like the following: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' msvcrt!memcpy + 0x33 php4ts!zend_strndup + 0x38 php4ts!zend_get_extension + 0xA0 php4ts!zend_hash_copy + 0x7B php4ts!zend_get_extension + 0xFB php4ts!zend_print_zval_r_ex + 0x999 php4ts!ts_resource_ex + 0x21F php4ts!ts_resource_ex + 0x98 php4isapi!HttpExtensionProc + 0x37 wam + 0x7A91 wam + 0x8634 RPCRT4!NdrServerInitialize + 0x45B RPCRT4!NdrStubCall2 + 0x1A5 RPCRT4!CStdStubBuffer_Invoke + 0x82 ole32!StgGetIFillLockBytesOnFile + 0xA270 ole32!StgGetIFillLockBytesOnFile + 0xA21F ole32!CoImpersonateClient + 0x1B8 + 0xFF6C8BE0 + 0x1132AE13 '. Of course I'm using the Release_TSDbg version of php4isapi rather than a release, so that's why I have a stack trace. All of this is with the current PHP_4_2_0 release branch. Joseph -Original Message- From: Rose, Billy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 2:54 PM To: 'Joseph Tate'; Php-Dev List Subject: RE: [PHP-DEV] zend questions and bug #15333 Forgot to mention, the algorithm in the MS lib is what is faulty. It overruns the buffer at times. Billy Rose [EMAIL PROTECTED] -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:41 PM To: Php-Dev List Subject: [PHP-DEV] zend questions and bug #15333 http://bugs.php.net/15333 I've narrowed down the problem, but can't seem to get anywhere with it. The state of the server when the problem occurrs: All serviceable threads have been killed or have timed out. A request is received prompting the spawning of a new thread. The new thread then goes through and copies the global_constants_table, but that has been corrupted somewhere causing an access violation when trying to dereference uninitialized memory. This happens every time the server has been idle for ~10 minutes after serving up php pages. Here are my questions that I haven't been able to track down yet. Hopefully someone can save me some time. 1. What code is executed when a thread times out? zend_shutdown never seems to run (or at least my breakpoints there never fire). 2. It appears that global_constants_table is not global nor constant, each thread has a separate copy. Why is this the case? And if it is meant to be, where is the original global_constants_table. What could be modifying it so that it cannot be copied when a new thread is started? 3. Where would be a good place to start to find the answers to the zend questions that I have as I track this down. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] zend questions and bug #15333
I've looked at it in the debugger immediately before the access violation and have found that both the pointer to the char* to be copied and the length are garbage, so it's not the lib. -Original Message- From: Rose, Billy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 3:29 PM To: 'Joseph Tate'; Rose, Billy; Php-Dev List Subject: RE: [PHP-DEV] zend questions and bug #15333 In your stack dump, the function call that bombed was memcpy in the MS lib. Looking at the source in zend_alloc.c, I find that the lib's memcpy function is used. The way I finally tracked down my problem was tedious as hell, but I put the MS debug macro just before the function that was failing (in this case zend_strndup). Then I single stepped into the MS function that was failing. This method was required because I was running a service. I bet if you write an adhoc my_memcpy function in C and byte for byte copy over the string, the problem goes away. memcpy uses the same 32 bit algorothm as the string functions. I sent in a bug report to MS about a year ago, but was blown off (swept under the rug rather perhaps?). The algorithm seems to blow up only under weird circumstances. Billy Rose [EMAIL PROTECTED] -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 2:05 PM To: Rose, Billy; Php-Dev List Subject: RE: [PHP-DEV] zend questions and bug #15333 zend_strndup is a php implementation. It does not use the strndup function available through MS's library. The problem occurs because a length of 100 or more is passed in, signifying to me that the source of that length has become corrupted or not initialized. I've traced that back to the global_constants_table structure. I no longer get the specific error mentioned in the bug report, but get an error in the same location under the same circumstances. My error looks like the following: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' msvcrt!memcpy + 0x33 php4ts!zend_strndup + 0x38 php4ts!zend_get_extension + 0xA0 php4ts!zend_hash_copy + 0x7B php4ts!zend_get_extension + 0xFB php4ts!zend_print_zval_r_ex + 0x999 php4ts!ts_resource_ex + 0x21F php4ts!ts_resource_ex + 0x98 php4isapi!HttpExtensionProc + 0x37 wam + 0x7A91 wam + 0x8634 RPCRT4!NdrServerInitialize + 0x45B RPCRT4!NdrStubCall2 + 0x1A5 RPCRT4!CStdStubBuffer_Invoke + 0x82 ole32!StgGetIFillLockBytesOnFile + 0xA270 ole32!StgGetIFillLockBytesOnFile + 0xA21F ole32!CoImpersonateClient + 0x1B8 + 0xFF6C8BE0 + 0x1132AE13 '. Of course I'm using the Release_TSDbg version of php4isapi rather than a release, so that's why I have a stack trace. All of this is with the current PHP_4_2_0 release branch. Joseph -Original Message- From: Rose, Billy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 2:54 PM To: 'Joseph Tate'; Php-Dev List Subject: RE: [PHP-DEV] zend questions and bug #15333 Forgot to mention, the algorithm in the MS lib is what is faulty. It overruns the buffer at times. Billy Rose [EMAIL PROTECTED] -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:41 PM To: Php-Dev List Subject: [PHP-DEV] zend questions and bug #15333 http://bugs.php.net/15333 I've narrowed down the problem, but can't seem to get anywhere with it. The state of the server when the problem occurrs: All serviceable threads have been killed or have timed out. A request is received prompting the spawning of a new thread. The new thread then goes through and copies the global_constants_table, but that has been corrupted somewhere causing an access violation when trying to dereference uninitialized memory. This happens every time the server has been idle for ~10 minutes after serving up php pages. Here are my questions that I haven't been able to track down yet. Hopefully someone can save me some time. 1. What code is executed when a thread times out? zend_shutdown never seems to run (or at least my breakpoints there never fire). 2. It appears that global_constants_table is not global nor constant, each thread has a separate copy. Why is this the case? And if it is meant to be, where is the original global_constants_table. What could be modifying it so that it cannot be copied when a new thread is started? 3. Where would be a good place to start to find the answers to the zend questions that I have as I track this down. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http
[PHP-DEV] Memory leak and possible cause of bug #15333
in the copy_zend_constant function it reads:
void copy_zend_constant(zend_constant *c)
{
c-name = zend_strndup(c-name, c-name_len);
if (!(c-flags CONST_PERSISTENT)) {
zval_copy_ctor(c-value);
if (c-flags CONST_EFREE_PERSISTENT) { /* persist_alloc()'d data */
persist_alloc(c-value);
}
}
}
I draw your attention to the first line in the function:
c-name = zend_strndup(c-name, c-name_len);
First of all, why is this string duplicated only to store it to the same
location? Secondly, is c-name freed somewhere else? Cause I can't see it
being freed. Seems like this line can be removed...
Joseph
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Memory leak and possible cause of bug #15333
I don't follow you. Why does it need to be copied? c-name already
contains the value. Old? New? c is c is c. Commenting out the code
causes other problems elsewhere (or seems to). I just don't understand why
it has to be done.
-Original Message-
--- Joseph Tate [EMAIL PROTECTED] wrote:
in the copy_zend_constant function it reads:
void copy_zend_constant(zend_constant *c)
{
c-name = zend_strndup(c-name, c-name_len);
if (!(c-flags CONST_PERSISTENT)) {
zval_copy_ctor(c-value);
if (c-flags CONST_EFREE_PERSISTENT) { /*
persist_alloc()'d data */
persist_alloc(c-value);
}
}
}
I draw your attention to the first line in the function:
c-name = zend_strndup(c-name, c-name_len);
First of all, why is this string duplicated only to store it to the same
location? Secondly, is c-name freed somewhere else? Cause I
can't see it
being freed. Seems like this line can be removed...
So c points to the old value and you need to copy the name and
the value to
the new one, name and value. and the way hashes and emalloc
works the memory
will be freed automatically.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Memory leak and possible cause of bug #15333
Gotcha. Guess I missed that there was another copy somewhere. I'm trying
to track down a problem with ISAPI that causes php to die and take down
everything with it. Thought I might have a handle on it. Thanks for the
clarification.
Joseph
-Original Message-
From: brad lafountain [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 08, 2002 4:25 PM
To: Joseph Tate; Php-Dev List
Subject: RE: [PHP-DEV] Memory leak and possible cause of bug #15333
hmm
ok
zend_constant *c, *b;
char *sname = myname;
c-name = name; // the c-name is just a pointer to the sname
//c-name = strdup(sname); // c-name would have it's own memory
b = c; //now b-name points to sname
free(b-name); // would try and free b-name which can't be done,
segfault!
so now you do this:
zend_constant *c, *b;
char *sname = myname;
c-name = strdup(sname); // c-name would have it's own memory
b = c; //now b-name points to a copy of sname
copy_zend_constant(b); //now b-name has its own memory
free(b-name); // now this will work no segfaults here
and if you look where copy_zend_constant it is only called when
you want to
copy constants from one hash to another.
- Brad
--- Joseph Tate [EMAIL PROTECTED] wrote:
I don't follow you. Why does it need to be copied? c-name already
contains the value. Old? New? c is c is c. Commenting out the code
causes other problems elsewhere (or seems to). I just don't
understand why
it has to be done.
-Original Message-
--- Joseph Tate [EMAIL PROTECTED] wrote:
in the copy_zend_constant function it reads:
void copy_zend_constant(zend_constant *c)
{
c-name = zend_strndup(c-name, c-name_len);
if (!(c-flags CONST_PERSISTENT)) {
zval_copy_ctor(c-value);
if (c-flags CONST_EFREE_PERSISTENT) { /*
persist_alloc()'d data */
persist_alloc(c-value);
}
}
}
I draw your attention to the first line in the function:
c-name = zend_strndup(c-name, c-name_len);
First of all, why is this string duplicated only to store
it to the same
location? Secondly, is c-name freed somewhere else? Cause I
can't see it
being freed. Seems like this line can be removed...
So c points to the old value and you need to copy the name and
the value to
the new one, name and value. and the way hashes and emalloc
works the memory
will be freed automatically.
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] proposed domxml funciton name changes:
I propose the following function name changes for clarity and consistency: Rename: domxml_node_insert_before - domxml_node_insert_node domxml_node_append_child - domxml_node_append_node Remove: alias to unlink (in favor of the more consistent unlink_node) domxml_node_new_child() (in favor of a domxml_doc_create_* domxml_node_add_child() combination) If I've misunderstood what something does, or why it's named in such a way, let me know. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/domxml php_domxml.c
Any objections to merging this into 4.2.0? -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: [PHP-CVS] cvs: php4 /ext/domxml php_domxml.c jtate Fri Apr 5 13:18:25 2002 EDT Modified files: /php4/ext/domxml php_domxml.c Log: Added unlink_node alias for consistency Index: php4/ext/domxml/php_domxml.c diff -u php4/ext/domxml/php_domxml.c:1.135 php4/ext/domxml/php_domxml.c:1.136 --- php4/ext/domxml/php_domxml.c:1.135Fri Apr 5 10:47:08 2002 +++ php4/ext/domxml/php_domxml.c Fri Apr 5 13:18:23 2002 @@ -16,7 +16,7 @@ +--+ */ -/* $Id: php_domxml.c,v 1.135 2002/04/05 15:47:08 chregu Exp $ */ +/* $Id: php_domxml.c,v 1.136 2002/04/05 18:18:23 jtate Exp $ */ /* TODO * - Support Notation Nodes @@ -329,6 +329,7 @@ PHP_FALIAS(has_attributes, domxml_node_has_attributes, NULL) PHP_FALIAS(node, domxml_node, NULL) PHP_FALIAS(unlink, domxml_node_unlink_node, NULL) + PHP_FALIAS(unlink_node, domxml_node_unlink_node, NULL) PHP_FALIAS(replace_node, domxml_node_replace_node, NULL) PHP_FALIAS(set_content, domxml_node_set_content, NULL) PHP_FALIAS(get_content, domxml_node_get_content, NULL) -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for php.ini-* as mentioned in commit for /ext/crack/crack.dsp
Here it is. Will someone with karma please commit it? Thanks, Joseph php.ini-patch Description: Binary data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch to php4ts.dsp
The Release_TSDbg target for the php4ts project does not build out of the box. Attached is a patch which adds the Ws2_32.lib to the linking list. Joseph php4ts.patch Description: Binary data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] question
a) Yes, if and only if memory has been allocated and you have to deallocate
it. Otherwise a memory leak occurs.
b) No if a is not the case.
-Original Message-
From: Vergoz Michael (SYSDOOR) [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 24, 2002 6:00 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] question
look this code :
char buffer[MAXPATHLEN];
char *p;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
if((p = VCWD_GETCWD(buffer, MAXPATHLEN)) == NULL) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
RETURN_STRING(buffer, 1);
in this code the char pointer 'p' is really needed ?
michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Unsigned Right Shift Sould there be a matching left shift?
-1 Even if it does make for consistency (which is debatable) anyone who uses the operator will also know that is the same as (one less character to type too). -Original Message- From: Jason Greene [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 24, 2002 2:37 AM To: PHP-Dev Cc: Andi Gutmans Subject: [PHP-DEV] Unsigned Right Shift Sould there be a matching left shift? Hello everyone, Andi and I have been talking offline regarding my unsigned right shift operator patch. We have decided to implement this change in ZE2; however, there is one thing left to be resolved before the functionality can be added. Currently the Unsigned Right Shift patch implements 2 new operators: (Unsigned Shift) = (Unsigned Shift Assign) In my initial patch I did not include the equivalent left shift operators because sign only affects a right shift. However, this does introduce a consistency problem, and so the question is should we implement and = and have them just be aliases to and =? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
Would there ever be a need to get the ASCII ftp_size? If not, the go ahead, but if there ever might be, you may want to add a parameter to ftp_size so that it behaves like ftp_get et all. The parameter could default to BINARY. Joseph -Original Message- From: Vlad Krupin [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 4:15 PM To: PHP Developers Mailing List Cc: [EMAIL PROTECTED] Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try Hi, this is the second try to get feedback and to make a fix to ftp_size() function. After bringing that issue up a few days back, I got response from Derick only with some concerns, which I'll address here. Please, respond or I'll just apply the patch because it makes sense to me and see what happens. First of all, ftp_size() function is broken. It will return different results for the same file depending on what function was called before it. To fix it, we have to set the mode of the ftp server session to BINARY rather than ASCII. It is a one-liner patch. Derick was concerned that this will change the state of the session without the user explicitly requesting it and we do not restore it. However, this is irrelevant since all the functions that depend on that state will set it for themselves: - ftp_nlist() and ftp_rawlist() already do just that - they just set the type to ASCII and do not restore it. - ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the type explicitly - other functions do not depend on transfer type (except for ftp_size() ). It was an obvious oversight not to make ftp_size() set the mode before requesting the size of a file (I would have never imagined that the size of the file differs depending on whether we do 'dir' in text mode or binary mode... duh!) So, to wrap it up. Making that change will not affect *any* other functionality of the ftp extension (you are welcome to read through the source - I just did that) and will fix ftp_size() to consistently return correct results. Question: Does anybody object to putting that change in, *and* also merging it into the release branch? This is an obvious bug, and the fix doesn't affect anything else. Vlad -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
I can condone that course of action. Go ahead and commit it. I'd make a not of it in the documentation so that somebody doesn't get seriously bitten by it. -Original Message- From: Vlad Krupin [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:08 PM To: [EMAIL PROTECTED] Cc: Joseph Tate; PHP Developers Mailing List Subject: Re: [PHP-DEV] FTP returns wrong file size (and a fix) - second try If someone needs an ASCII size, they need to scream and file a bug report and then I'll implement it. This function has not been working properly for ages and no-one complained. This way at least it will work consistently and make sense. Optional ASCII mode size will require a bloat (like an optional parameter) :(. Vlad [EMAIL PROTECTED] wrote: On Mon, 18 Mar 2002, Joseph Tate wrote: Would there ever be a need to get the ASCII ftp_size? If not, the go ahead, but if there ever might be, you may want to add a parameter to ftp_size so that it behaves like ftp_get et all. The parameter could default to BINARY. That sounds like a good idea to me. I can't think of a way why it would be useful, but it doesn't hurt either. I'd go for the ftp_size() with default BINARY, and optional ASCII mode size. (And it's fine with me to merge it) regards, Derick Joseph -Original Message- From: Vlad Krupin [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 4:15 PM To: PHP Developers Mailing List Cc: [EMAIL PROTECTED] Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try Hi, this is the second try to get feedback and to make a fix to ftp_size() function. After bringing that issue up a few days back, I got response from Derick only with some concerns, which I'll address here. Please, respond or I'll just apply the patch because it makes sense to me and see what happens. First of all, ftp_size() function is broken. It will return different results for the same file depending on what function was called before it. To fix it, we have to set the mode of the ftp server session to BINARY rather than ASCII. It is a one-liner patch. Derick was concerned that this will change the state of the session without the user explicitly requesting it and we do not restore it. However, this is irrelevant since all the functions that depend on that state will set it for themselves: - ftp_nlist() and ftp_rawlist() already do just that - they just set the type to ASCII and do not restore it. - ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the type explicitly - other functions do not depend on transfer type (except for ftp_size() ). It was an obvious oversight not to make ftp_size() set the mode before requesting the size of a file (I would have never imagined that the size of the file differs depending on whether we do 'dir' in text mode or binary mode... duh!) So, to wrap it up. Making that change will not affect *any* other functionality of the ftp extension (you are welcome to read through the source - I just did that) and will fix ftp_size() to consistently return correct results. Question: Does anybody object to putting that change in, *and* also merging it into the release branch? This is an obvious bug, and the fix doesn't affect anything else. Vlad -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /main php.h
Ok. From the MSDN (Which is available for free perusal from msdn.microsoft.com): --Begin M$ Technobabble-- The ANSI assert macro is typically used to identify logic errors during program development, by implementing the expression argument to evaluate to false only when the program is operating incorrectly. After debugging is complete, assertion checking can be turned off without modifying the source file by defining the identifier NDEBUG. NDEBUG can be defined with a /D command-line option or with a #define directive. If NDEBUG is defined with #define, the directive must appear before ASSERT.H is included. assert prints a diagnostic message when expression evaluates to false (0) and calls abort to terminate program execution. No action is taken if expression is true (nonzero). The diagnostic message includes the failed expression and the name of the source file and line number where the assertion failed. --snip-- The assert routine is available in both the release and debug versions of the C run-time libraries. Two other assertion macros, _ASSERT and _ASSERTE, are also available, but they only evaluate the expressiosn passed to them when the _DEBUG flag has been defined. --End M$ Technobabble-- I think the key here is that NDEBUG must be defined before the #include assert.h in order to disable assertions. I personally don't care which assert is used under Windows. I don't really have time to test the VC++ build right now either, however, please remember that while that whole discussion was going on the majority of the American continents were asleep. And it's the North Americans that _must_ use Microsoft products due to obsolete management and too much marketing hype. Joseph Who has become aware that the majority of traffic on these two lists happens when I'm asleep. -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 5:34 AM Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; php-dev Subject: [PHP-DEV] Re: [PHP-CVS] Re: cvs: php4 /main php.h [EMAIL PROTECTED] wrote: On Fri, 15 Mar 2002, Yasuo Ohgaki wrote: According to Derick's post, VC defines NDEBUG somewhere else. Following patch should fix redfined warnings. This doesn't seem like a good idea, VC++ might be using NDEBUG for very different reasons. How did you come up with the name NDEBUG? Accoding to ISO9899(ANSI C) standard, NDEBUG is used for assert.h. VC may define/use it some other reasons? I just don't have any idea. Do I need #define assert(expr) ASSERT(expr) also for VC? I've no idea, sebastian? I hope someone confirm how it should be treated under VC. -- Yasuo Ohgaki Derick --- php.h.~1.161.~ Fri Mar 15 15:36:56 2002 +++ php.h Fri Mar 15 18:47:43 2002 @@ -63,18 +63,18 @@ #include php_regex.h -#ifndef PHP_WIN32 #if HAVE_ASSERT_H #if PHP_DEBUG #undef NDEBUG #else +#ifndef NDEBUG #define NDEBUG +#endif /* NDEBUG */ #endif #include assert.h #else /* HAVE_ASSERT_H */ #define assert(expr) ((void) (0)) #endif /* HAVE_ASSERT_H */ -#endif /* PHP_WIN32 */ #define APACHE 0 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] I feel kind of silly that I can't track this down, but...
I've got the current CVS version of php configured as follows:
EXTENSION_DIR=/home/jtate/php-dev/php4/modules \
./configure --with-zlib-dir --with-dom=shared --with-dom-xslt --with-dom-exs
lt --without-mysql --without-ldap
Everything compiles and builds just fine, but when I run the following
script:
?php
if (!function_exists('xmldoc')) {
dl('domxml.so');
}
$xml = 'docnode//doc';
$xmlObj = xmldoc($xml);
?
I get the following output.
X-Powered-By: PHP/4.3.0-dev
Content-type: text/html
br /
bWarning/b: Unable to load dynamic library
'/home/jtate/php-dev/php4/modules/
domxml.so' - /home/jtate/php-dev/php4/modules/domxml.so: undefined symbol:
empty_s
tring in b/home/jtate/php-dev/php4/small.php/b on line b3/bbr /
br /
bFatal error/b: Call to undefined function: xmldoc() in
b/home/jtate/php-d
ev/php4/small.php/b on line b6/bbr /
Near as I can tell, the only place where empty_string is defined on my
entire system is in Zend/zend_variables.c. What am I missing? Is the
module not linking properly with the Zend engine? I'd really like to know
what's going on, so don't go fixing it in CVS without telling me what was
wrong.
Thanks,
Joseph
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Not getting output I expect on all pages
Ask this question on the php-general list. This mail list is for issues involving the development _of_ PHP, not development _in_ PHP. Joseph -Original Message- From: Liam Gibbs [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Not getting output I expect on all pages Hi guys, recently new here. I get the code at the end of this message whenever I load a page that redirects to another page (i.e. I use the 'header(Location: page.php)' command). What's going on? It doesn't do this when the page doesn't redirect, only when it does redirect. Any thoughts? This is PHP4, if that helps, but it does the same with 3 (tried both versions). And now for the code: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META content=text/html; charset=iso-8859-1 http-equiv=Content-Type/HEAD BODY/BODY/HTML __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [patch] domxml ./. trivial cleanup
The maintainer seems to be AWOL. I've never heard from him anyway. I'll
commit the change though if there are no objections. It seems like instead
of an assumption that found will always be !NULL, we should assert that it
be !NULL.
-Original Message-
From: Lukas Schroeder [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 07, 2002 3:39 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] [patch] domxml ./. trivial cleanup
hi!
the patch below is against cvs as of several minutes ago...
doing
if (! found)
*found = ...;
i did not change it into if (found) either, b/c found is a
non-optional parameter of internally used functions; it will not be
NULL ever.
regards,
-lukas
PS: is there currently a maintainer of the domxml code who should
be CC'd ?
Index: php_domxml.c
===
RCS file: /repository/php4/ext/domxml/php_domxml.c,v
retrieving revision 1.119
diff -u -r1.119 php_domxml.c
--- php_domxml.c 7 Mar 2002 16:34:13 - 1.119
+++ php_domxml.c 7 Mar 2002 20:29:09 -
@@ -718,9 +718,7 @@
{
zval *wrapper;
- if (! found) {
- *found = 0;
- }
+ *found = 0;
if (!obj) {
MAKE_STD_ZVAL(wrapper);
@@ -825,9 +823,7 @@
zval *wrapper;
int rsrc_type;
- if (! found) {
- *found = 0;
- }
+ *found = 0;
if (!obj) {
MAKE_STD_ZVAL(wrapper);
@@ -911,9 +907,7 @@
char *content;
int rsrc_type;
- if (! found) {
- *found = 0;
- }
+ *found = 0;
if (!obj) {
MAKE_STD_ZVAL(wrapper);
@@ -3355,9 +3349,7 @@
zval *wrapper;
int rsrc_type;
- if (! found) {
- *found = 0;
- }
+ *found = 0;
if (!obj) {
MAKE_STD_ZVAL(wrapper);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] new bug status
I like it, but first I'd like to see a file upload option to upload the patch much like bugzilla has. -Original Message- From: Robin Ericsson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 9:17 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] new bug status I mentioned it to Derick on IRC, and he seemed to like it so I'll throw the everybody else :) I feel that alot of patches and input from users are often missed by developers (see earlier mail regarding patches :) An easy fix for this would be to have a new status called patch or whatever. When someone enters or updates a bug, and maybe provides a patch, then somebody (someone with bug access :), updates the bug, and sets it to status patch. It is then a lot easier for developer to search the bug database for posted patches, and review them, instead of find them lying there for several months, without anyone have time to find/look at them. -- Robin Ericsson lobbin at localhost dot nu The secret of flying is to throw yourself at the ground, and miss. -- Douglas Adams -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New Module
I agree that there should be a better way to store db connection data and such in PHP. Since php scripts have to be readable by a webserver, that usually makes them readable to the users on the box. Not necessarily, but it requires custom setup to have it otherwise, and unless you have a true access control file system, forget about making your scripts writable to one group, read-only to the webserver and non-readable to every other user with access to the box. Apache seems to be quite picky about file permissions as that's bitten us a few times in the last week or so. What I propose is the following. It makes life easier for the 95% of the cases where there is one database being used most of the time. Each database module (pgsql, mysql, oracle, etc) provides an additional function, register_connection(), which takes the same arguments as the (pg|mysql|etc)_connect() function for that database and stores the connect data in some unreadable format on the filesystem perhaps within the php.ini file itself. This function need only be called once, perhaps as a command line program similar to htpasswd. Each call then to _connect() with no arguments will pull the database connection information written with register_connection() to make a connection. Calls to _connect() with arguments will perform the way it does now. That way if the user gets access to your site, he still will be unable to do anything with your database without knowing something about its layout. I.e. he can't do an _exec(DELETE FROM customer_data) unless he knows that there is a customer_data table in that database. On Linux mcrypt would be used. On windows, some other two way crypt module would be used (J Smith mentioned Crypto++). A feature such as this would place PHP a head and shoulder above any other web scripting language that I know of. (I guess with C CGI modules that are compiled you can't read the db connection info, but who wants to write CGI or apache modules in C?) Comments? I just thought of another use for this New Module too. It would have to be extended, but: I would like to store a number of configuration or site specific information in some non-user-readable way. This includes path information, SQL queries. MD5 keys. Not sure exactly how this would shape up without some kind of admin tool that ran on the server, but having this kind of embedded databasing system would be pretty cool. Anyway, if you've been able to follow my meandering, congratulations. I just wanted to put in my $.02. I definitely don't have time to develop this kind of thing right now, but think it would be very useful. Joseph -Original Message- From: Keyser Soze [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 10:55 AM Cc: PHP-DEV Subject: Re: [PHP-DEV] New Module Not if the webserver is in another machine, he could have gained access to my system thru a security flaw in my webserver, one that doesn't have in my database server. And he just could create the script in a tempfolder and execute it if php is a cgi module, unless he has apache html write rights. I thought of this extension to make it harder for a hacker to access data, and easier for admins to detect the access from that data. But I thought a workaround for this caseI can modify the sources so cfg_get may store the last script who accessed that file, or maybe cfg_set could just grant access to one scriptthis could make impossible for anyone to create another script just to get it. I'm new in extension development, so I don't know if it's possible to know inside my function what script is calling it. hmmm, i hadn't noticed the PHP Licensethat sounds ok for me. regards, Keyser Soze - Original Message - From: Peter Petermann [EMAIL PROTECTED] To: Keyser Soze [EMAIL PROTECTED]; Robin Ericsson [EMAIL PROTECTED] Cc: PHP-DEV [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 12:12 PM Subject: Re: [PHP-DEV] New Module it's much easier to detect a modification of a script instead of just a cat dbconf.php. no need to modify a script. if a hacker has access to your webserver, in most cases he will be able to access your db server too. if not, in case of your extension it shouldnt be hard for him creating a small script for looking up the data in your tempfolder, gaining the data, and deleting it this is from point of detection the same class as doing a cat dbconf.php the Point is: your extension is not changing security. btw: why you want to put it under GPL? most extensions have PHP License, that could conflict. regards, Peter Petermann -- Homepage: www.cyberfly.net PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] PHP Infos: www.php-center.de - [EMAIL PROTECTED] VL-SRM Homepage: www.vl-srm.net - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/
RE: [PHP-DEV] New Module
What Brad is suggesting doesn't take away from your module, just makes it easier to use from php land. No need to write your own crypt functions in C, just write them in PHP and use them as callbacks. Of course leaving that option for advanced users is a good idea. I personally don't think that I would be writing custom crypt functions, so I would like a crypto++ plugin to do that for me. Joseph -Original Message- From: Keyser Soze [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:03 PM To: Brad Fisher; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] New Module but that's what my module is meant for Keyser Soze - Original Message - From: Brad Fisher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 3:03 PM Subject: Re: [PHP-DEV] New Module J Smith wrote: I hesitate to mention this because I don't want to get stuck in a corner here, but I've been working on and off on a PHP encryption extension for precisely the reasons you mention. I'm using Crypto++, a public ... This sounds to me like one of the better ways to do it. Just have an extension that does two-way encryption, and supports several different algorithms. For those people who whant to define their own algorithms, why not have a way to register a new crypt/decrypt callback methods either developed in PHP or loadable module? Something like: bool crypto_register_algorithm(string name, function crypt, function decrypt) Then crypt and decrypt could have function headers similar to (perhaps this is oversimplified): string crypt(string data, mixed key) I don't think the module would need to write configuration files, etc. That could be handled with PHP by the developer, or by another PHP extension/function which can write such files. Just babbling, -Brad -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New Module
Well, J Smith has mentioned Crypto++. I haven't looked into it, but that sounds like a good little module as a substitute for mcrypt. If he truly is working on a php extension using it, then it's purely acedemic to add it to your module. -Original Message- From: Keyser Soze [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:19 PM To: Joseph Tate; Brad Fisher; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] New Module I agree, so I think this module could be packaged with a default mycrypt library to make this easier Any idea? Keyser Soz - Original Message - From: Joseph Tate [EMAIL PROTECTED] To: Keyser Soze [EMAIL PROTECTED]; Brad Fisher [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 3:15 PM Subject: RE: [PHP-DEV] New Module What Brad is suggesting doesn't take away from your module, just makes it easier to use from php land. No need to write your own crypt functions in C, just write them in PHP and use them as callbacks. Of course leaving that option for advanced users is a good idea. I personally don't think that I would be writing custom crypt functions, so I would like a crypto++ plugin to do that for me. Joseph -Original Message- From: Keyser Soze [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:03 PM To: Brad Fisher; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] New Module but that's what my module is meant for Keyser Soze - Original Message - From: Brad Fisher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 3:03 PM Subject: Re: [PHP-DEV] New Module J Smith wrote: I hesitate to mention this because I don't want to get stuck in a corner here, but I've been working on and off on a PHP encryption extension for precisely the reasons you mention. I'm using Crypto++, a public ... This sounds to me like one of the better ways to do it. Just have an extension that does two-way encryption, and supports several different algorithms. For those people who whant to define their own algorithms, why not have a way to register a new crypt/decrypt callback methods either developed in PHP or loadable module? Something like: bool crypto_register_algorithm(string name, function crypt, function decrypt) Then crypt and decrypt could have function headers similar to (perhaps this is oversimplified): string crypt(string data, mixed key) I don't think the module would need to write configuration files, etc. That could be handled with PHP by the developer, or by another PHP extension/function which can write such files. Just babbling, -Brad -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] cracklib under Windows
What's the status of cracklib support under windows? Has it even been attempted? Is anyone working on it? We're going to need to get it going, but I was wondering if anyone else has gotten started on this so that we could pool resources. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: jtate
I'd like to help with the DOM-XML extension, getting it up to snuff. Filling in the holes, etc. I've already submitted one patch, and feel I can help a very strapped development team. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Bug #15530 Updated: conent of node node correct reading new DOM value after set_content of node
Ok, try the following code:
function getContent ($n)
{
if (!($children = $n-children())) return '';
$content = '';
foreach ($children as $c) {
if ($c-type == XML_TEXT_NODE) {
$content .= $c-content;
}
}
return $content;
}
Then use getContent($n) rather than $n-content. This could fix your
problem, but I'm not sure. It still uses the -content property (though in
a TEXT_NODE context). I don't actually make changes and then read back the
contents in any of my code, so this is new to me.
As for the time frame for the next release of php? I don't know.
Joseph
-Original Message-
From: Rob Richards [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 13, 2002 11:42 AM
To: Joseph Tate
Subject: Re: Bug #15530 Updated: conent of node node correct reading new
DOM value after set_content of node
Management's definition of a custom build is any package or port
that we use
not coming from a maintainer - go figure. This includes grabbing CVS
updates. Losing battle trying to argue this with them.
We have built a package for RedHat 7.2, 7.1 as well as FreeBSD, but the
ultimate server is out of our control and they will only use the FreeBSD
ports they can pull from within it.
Basically, we are stuck with our code needing to run on the
FreeBSD version
they run which right now only is up to revision 1.90 of the domxml code.
Do you happen to know any time frame for a next release? This may not be
much of a problem depending upon that.
Thanks,
Rob
- Original Message -
From: Joseph Tate [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Php-Dev List [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 11:19 AM
Subject: RE: Bug #15530 Updated: conent of node node correct
reading new DOM
value after set_content of node
You kind of have to have a custom php build anyway because DOMXML stuff
isn't part of the RH php installation. I've got rpms for RH 7.2 if that
will help. They don't have the get_content stuff, but I could
add that to
my custom patch (that fixes bug #14934) no problem. Besides,
it'll be in
the next release; it's not custom code in the purest definition of the
term.
Joseph
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 13, 2002 11:04 AM
To: [EMAIL PROTECTED]
Subject: Bug #15530 Updated: conent of node node correct
reading new DOM
value after set_content of node
ID: 15530
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating System: RedHat 7.2
PHP Version: 4.1.1
New Comment:
Any other workaround for the get_content problem? We can use a custom
php build on our development machines, but cant on the server
where the
code will actually be going.
Thanks
Previous Comments:
[2002-02-13 10:43:55] [EMAIL PROTECTED]
The problem is that the content property is going away, so that
property is not set. This is why it's not being updated. It's being
replaced by a get_content() function. This is in CVS at this very
moment.
As for the appending of xml contents, the comment in the code is as
follows:
// FIXME: another gotcha. If node has children, calling
// xmlNodeSetContent will remove the children - we loose the zval's
// To prevent crash, append content if children are set
I think if you just used the get_content() function instead of the
-content property that your problem would go away. Of course you're
going to have to pull it from CVS.
[2002-02-12 16:18:23] [EMAIL PROTECTED]
The following simplied script shows that when we update the value of a
node, the DOM is updated as shown through the dump. When you try to
read the content of the node however, it returns the origional value.
If this is a bug, is there any known workaround to get the desired
result?
Also, we had to use the set_content as provided in the script because
if a node already has a value and we try to call set_content directly
on the node rather than on the the text element (value node), it
appends the data to the node rather than overwriting the exisitng
value.
XPath is used in here as our real XML data is quite complex so needed
to illustrate how we were finding the correct node.
?
$xmltest = root_nodenode1ORG VALUE/node1/root_node;
$mydoc = xmldoc($xmltest);
echo pre.$mydoc-dumpmem()./prebr;
$ctx=$mydoc-xpath_new_context();
$query_xo = xpath_eval($ctx,/root_node/node1);
$oNode = $query_xo-nodeset[0];
if (is_null($oNode)) {
$root = $$mydoc-root();
$root-new_child(node1, empty);
} else
[PHP-DEV] DOMXML maintainer
Who is the domxml maintainer? I would like to make some of the functions a little more useful/robust, less verbose (about warning messages, and so forth). Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
