Re: [PHP-DEV] New Build System Committed to HEAD
For some reason ncurses ends up twice in internal_functions_cli.c; I can't figure out why though: phpext_overload_ptr, phpext_ncurses_ptr, phpext_ncurses_ptr, phpext_mysql_ptr, xmm. i couldn't verify this... (updated before 10-20 minutes) phpext_overload_ptr, phpext_ncurses_ptr, phpext_mysql_ptr, Derick b. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates
hi Daniel, when I look at /ext/ (PHP source) just to pick a random example: what's 'vpopmail' doing there (no personal offense to the author, really randomly picked)? I mean, vpopmail has it's own deamon and an interface written in PHP (ok, that one is ugly, it depends on global variables and has to be rewritten), but why create a /compiled/ module for this? doesn't make sense to me. no gain in performance. and even the module is WORSE than the PHP interface, because it requires you to run PHP as CGI binary, fiddling around with sudo etc.. (whereas the PHP just opens a socket to the vpopmail-daemon, sends some commands etc..) i would not like to put any offense but you are technicaly wrong - the fastest way to access vpopmail functionality is to call native api instead execute something external. this can be observed on high loaded servers of course. one cannot skip the sudo stuff with vpopmail anyway - you must be root to manage domains, and at least vpopmail to manage users. when one really need to manage vpopmail at high web load she can compile a separate apache for the management site and run it under vpopmail instead using slow CGIs. prehapse you mess vpopmail with vmailmgr - the first one have management daemon, second does not (at least an official one). the third reason is the unified interface - vpopmail command line tools differ between versions and one have to tweak her script for each different version. about the first part of your email - i would vote with two hands for PEAR repository of php modules written in C, vpopmail extension's place is definitely there anyone interested in /ext/daniel/ printing out some greetings to my friends? how about daniel_greet_his_friends(); and daniel_send_email_to_his_friends(), etc? :)) b. -- 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]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity
BB why not = then. imo the parser will easily distinguish array BB definition from an expression The last thing we need is symbol reuse. The parser can distinguish a lot of things, the problem is that the human developer would be confused. = has a clear meaning in PHP, adding other meaning to it would have very high WTF factor for the developer. sure. the F'ed WTF... :) anyway this is a better solution if the best syntax :: makes stuff slow. thinking in general a namespace is very close to a class, so if there's no tech reasons not to make a single implementation of both it'd be perfect b. -- 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]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity
why not = then. imo the parser will easily distinguish array definition from an expression b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Zeev Suraski [EMAIL PROTECTED]; Stig Sæther Bakken [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 11:02 PM Subject: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity Well the difference is that C++ can figure out what to do at compile-time. I don't think we can which means that it would put more logic into run-time which is a bad thing IMO (especially for something new like this). Or can you think of a way to differ between these at compile-time? Andi At 09:56 PM 9/30/2001 +0200, Zeev Suraski wrote: :: is taken, but why not do it the C++ way? It also uses :: for both classes and namespaces. Zeev At 21:35 30-09-01, Stig Sæther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] Hey, I just started playing around with the parser to support the namespaces syntax Stig laid out in his RFC. I think I've thought of an ambiguity (with constants) which makes me wonder how feasible the proposed syntax is. Consider the following expression: $test?FOO:BAR:BARBARA Would this mean that the person meant $test?(FOO):(BAR:BARBARA) or $test?(FOO:BAR):BARBARA? Okay, is there another character we can use? Doesn't look that way. Maybe we need to use two characters then? Since both :: and - are taken, // is the best suggestion I can come up with. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] -- 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]
Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)
please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- 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] -- 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] -- 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]
Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)
currently i am rewriting the nl2br stuff. two reasons: 1. current ver does not handle nicely text with mixed dos/unix/mac line endings 2. using generic str_replace for exactly 1 or 2 chars is really slower (IMHO this is used too often to pay the 200-500 bytes code overhead) when it is stable, i'll post a patch b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Boian Bonev [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Sascha Schumann [EMAIL PROTECTED] Sent: Friday, September 21, 2001 7:13 PM Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- 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] --- - -- 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
Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)
indeed boyer-moore is slower for short strings... anyway i have made a patch that addresses both mac/unix/dos line endings and also works with files that have different endings inside (imagine a file created on *nix edited under windows), which is a very common case. it is slightly slower than current ver (89 seconds before patch/92 seconds after patch for a very big test) but makes stuff more compatible. b. - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Andi Gutmans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 21, 2001 8:14 PM Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) On Fri, 21 Sep 2001, Andi Gutmans wrote: Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. When I added some support for MAC line endings, I was told boyer_str_to_Str() was the faster method... so I choose that one. Not knowing that it was still experimental. Maybe place a comment about things being experimental in the source next time would guard against this kind of problems Derick Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die
[PHP-DEV] Fw: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c
no response, so i noticed that i forgot to cc: the dev list.
b.
- Original Message -
From: Boian Bonev [EMAIL PROTECTED]
To: Derick Rethans [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, September 09, 2001 10:29 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c
hi,
IMHO this is incorrect again :))
you should not return when there are some translations, because it is a
common practice to have code with mixed line endings [most commonly
win/unix].
the perfect solution [only like algorithm] is:
ereg_replace('\n\r?|\r','br //')
talking for speed - as far as i know boyer-moore algorithm is not good
with
short strings :)) so instead of three times calling boyer_str_to_str, it
will be better to scan the string once and code the above regexp in two
ifs
;)
anyway not be only speaking, if it will be helpful, i can send a patch on
this...
b.
- Original Message -
From: Derick Rethans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 09, 2001 3:55 PM
Subject: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c
derick Sun Sep 9 08:55:48 2001 EDT
Modified files:
/php4/ext/standard php_string.h string.c
Log:
- Really fix nl2br now... it's actaulyl faster now
Index: php4/ext/standard/php_string.h
diff -u php4/ext/standard/php_string.h:1.51
php4/ext/standard/php_string.h:1.52
--- php4/ext/standard/php_string.h:1.51 Tue Sep 4 05:35:53 2001
+++ php4/ext/standard/php_string.h Sun Sep 9 08:55:48 2001
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: php_string.h,v 1.51 2001/09/04 09:35:53 sterling Exp $ */
+/* $Id: php_string.h,v 1.52 2001/09/09 12:55:48 derick Exp $ */
/* Synced with php 3.0 revision 1.43 1999-06-16 [ssb] */
@@ -117,7 +117,7 @@
PHPAPI void php_trim2(zval **str, zval **what, zval *return_value, int
mode TSRMLS_DC);
PHPAPI void php_strip_tags(char *rbuf, int len, int state, char *allow,
int allow_len);
-PHPAPI void php_char_to_str(char *str, uint len, char from, char *to,
int
to_len, pval *result);
+PHPAPI int php_char_to_str(char *str, uint len, char from, char *to,
int
to_len, pval *result);
PHPAPI void php_implode(zval *delim, zval *arr, zval *return_value);
PHPAPI void php_explode(zval *delim, zval *str, zval *return_value, int
limit);
Index: php4/ext/standard/string.c
diff -u php4/ext/standard/string.c:1.238
php4/ext/standard/string.c:1.239
--- php4/ext/standard/string.c:1.238 Sun Sep 9 07:42:36 2001
+++ php4/ext/standard/string.c Sun Sep 9 08:55:48 2001
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: string.c,v 1.238 2001/09/09 11:42:36 derick Exp $ */
+/* $Id: string.c,v 1.239 2001/09/09 12:55:48 derick Exp $ */
/* Synced with php 3.0 revision 1.193 1999-06-16 [ssb] */
@@ -2473,10 +2473,11 @@
/* {{{ php_char_to_str
*/
-PHPAPI void php_char_to_str(char *str, uint len, char from, char *to,
int
to_len, zval *result)
+PHPAPI int php_char_to_str(char *str, uint len, char from, char *to,
int
to_len, zval *result)
{
- int char_count=0;
- char *source, *target, *tmp, *source_end=str+len, *tmp_end=NULL;
+ int char_count = 0;
+ int replaced = 0;
+ char *source, *target, *tmp, *source_end=str+len, *tmp_end = NULL;
for (source=str; sourcesource_end; source++) {
if (*source==from) {
@@ -2486,7 +2487,7 @@
if (char_count==0) {
ZVAL_STRINGL(result, str, len, 1);
- return;
+ return 0;
}
Z_STRLEN_P(result) = len + (char_count * (to_len - 1));
@@ -2495,6 +2496,7 @@
for (source = str; source source_end; source++) {
if (*source == from) {
+ replaced = 1;
for (tmp = to, tmp_end = tmp+to_len; tmp tmp_end; tmp++) {
*target = *tmp;
target++;
@@ -2505,6 +2507,7 @@
}
}
*target = 0;
+ return replaced;
}
/* }}} */
@@ -2992,13 +2995,12 @@
if (new_length != (*str)-value.str.len)
RETURN_STRINGL (tmp, new_length, 0);
efree (tmp);
- /* Mac style line-endings */
- tmp = boyer_str_to_str((*str)-value.str.val, (*str)-value.str.len,
\n\r, 2, br /\n\r, 8, new_length);
- if (new_length != (*str)-value.str.len)
- RETURN_STRINGL (tmp, new_length, 0);
- efree (tmp);
- /* Unix style line-endings */
- php_char_to_str((*str)-value.str.val,(*str)-value.str.len, '\n',br
/\n, 7, return_value);
+
+ /* Mac / Unix style line-endings */
+ if (php_char_to_str((*str)-value.str.val,(*str)-value.str.len,
'\n',br /\n, 7, return_value))
+ return;
+ efree (Z_STRVAL_P(return_value));
+ php_char_to_str((*str)-value.str.val,(*str)-value.str.len, '\r',br
/\r, 7, return_value);
}
/* }}} */
@@ -3786,6 +3788,6 @@
* tab-width: 4
* c-basic-offset: 4
* End:
- * vim600: noet sw=4 ts=4 tw=78 fdm=marker
- * vim600: noet sw=4 ts=4 tw=78
+ * vim600: noet sw=4 ts=4 fdm=marker
Re: [PHP-DEV] Better shell scripting
i can see just one reason - most people use the same php binary both for cgi and shell scripting. if this change is to be introduced in php then at least three builds will be performed - for shell, cgi and web server module. btw what happened with the change to the build system to allow simultaneous building of both cgi-sapi and another one? b. - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: Stig Sæther Bakken [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 07, 2001 6:00 PM Subject: Re: [PHP-DEV] Better shell scripting On Fri, 07 Sep 2001, Stig Sæther Bakken wrote: What if we introduced a -p option to PHP that starts the Zend parser in PHP mode? For any other files (include/require), it starts in HTML mode though. How about we have a separate sapi backend that really does all this stuff properly without relying on command-line options (which I hate)? This suggestion has been made long ago, so what's stopping us? -Andrei Everything should be made as simple as possible, but not simpler. -- Albert Einstein -- 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] -- 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]
Re: [PHP-DEV] Warning
At link I'm getting gcc: unrecognized option `-prefer-non-pic' My gcc version: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) It's not an error but is this option really necessary? i've seen in yesterday... maybe it makes things a bit faster/smaller. i do not know exactly how, but if it does not break non-gcc compilers (it will if it appear to them, perhapse) why not? b. -- 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]
Re: [PHP-DEV] Warning
At link I'm getting gcc: unrecognized option `-prefer-non-pic' My gcc version: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) It's not an error but is this option really necessary? i've seen in yesterday... maybe it makes things a bit faster/smaller. i do not know exactly how, but if it does not break non-gcc compilers (it will if it appear to them, perhapse) why not? I'm currently considering ripping out automake completely. As a side-effect that problem would go away, too. isn't it easier fixing automake itslef? or there is some non gnu stuff it cannot held? b. -- 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]
Re: [PHP-DEV] Bug #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions
then maybe close the related bug 10136... or better reopen both, since this is a problem. although it would be better if win32 smtp code is made more consistent and compatible with the unix sendmail one Making Cc and cc both work is a one-line fix. (Patch attached, but as I can not test this, I didn't commit). But while looking at the code, I see nothing about Bcc. Strange, or I'm i missing something? sure but not. you do not check for cC and CC :) the best way is to use case insesitive strstr (this shall not be so hard to code) there is one more prob - looking for \r\n exact match. in case of \n terminated input, this call returns NULL and logic goes to alloc deadly too much ram. about bcc - yes it is missing, but as far as i remember i have seen it eighter in an older version of this code, or in another related code. it must be processed exactly like cc. b. -- 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]
[PHP-DEV] Bug #11010: current cvs cannot configure
From: [EMAIL PROTECTED] Operating system: Linux glibc 2.1 PHP version: 4.0 Latest CVS (2001-05-22) PHP Bug Type: *Install and Config Bug description: current cvs cannot configure after upgrading libtool to 1.4 i have upgraded automake and autoconf to latest stable versions, here is the result: buildconf: checking installation... buildconf: autoconf version 2.50 (ok) build/buildcheck.sh: test: 4-p1: integer expression expected buildconf: automake version 1.4-p1 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure ./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion ./aclocal.m4:452: PHP_SUBST is expanded from... ./aclocal.m4:904: the top level rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: error: shell error while sourcing /tmp/ah26273/traces.sh in build/buildcheck.sh: first problem - automake version is 1.4-p1 and this check fails: IFS=.; set $am_version; IFS=' ' if test $1 = 1 -a $2 -lt 4 || test $1 -lt 1; then fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:25:01 @@ -40,7 +40,7 @@ fi # automake 1.4 or newer -am_version=`automake --version 2/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* *$//'` +am_version=`automake --version 2/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* +*$//' -e 's/-/./'` if test $am_version = ; then echo buildconf: automake not found. echoYou need automake version 1.4 or newer installed second problem - after double checking for libtool, $libtool is set to `which libtool` or `which glibtool`. in the check if libtool and automake are in the same path again which is used that is incorrect because which /bin/libtool founds nothing. fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:30:21 @@ -81,7 +81,7 @@ fi am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'` -lt_prefix=`which $libtool | sed -e 's#/[^/]*/[^/]*$##'` +lt_prefix=`echo $libtool | sed -e 's#/[^/]*/[^/]*$##'` if test $am_prefix != $lt_prefix; then echo WARNING: automake and libtool are installed in different echo directories. This may cause aclocal to fail. i'd update this bug when i find what else is going wrong -- Edit Bug report at: http://bugs.php.net/?id=11010edit=1 -- 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]
Re: [PHP-DEV] Bug #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions
hi,
then maybe close the related bug 10136...
although it would be better if win32 smtp code is made more consistent and
compatible with the unix sendmail one
b.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 22, 2001 4:33 AM
Subject: [PHP-DEV] Bug #9859 Updated: mail() doesn't send cc or bcc as in
the manual instructions
ID: 9859
Updated by: danbeck
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Mail related
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
If this is the case, then I'm closing this bug report and I will document
the behavior under the mail function.
Previous Comments:
--
-
[2001-05-22 01:45:29] [EMAIL PROTECTED]
see also bug #10136
the facts are: mail on win32 require rn newlines
also it is case sensitive on Cc: and Bcc: - it will not honour them if
spelled any other way.
here is the offending code (located in win32/sendmail.c):
if (headers (pos1 = strstr(headers, Cc:))) {
pos2 = strstr(pos1, rn);
tempMailTo = estrndup(pos1, pos2-pos1);
token = strtok(tempMailTo, ,);
i do not have win32 build env setup so cannot fix this
--
-
[2001-05-21 05:06:18] [EMAIL PROTECTED]
I've corrected the Cc: and Bcc: problems in the mail() example, but I'm
reclassifying this as a Mail Function problem. Is it necessary for the
win32 version of the mail() function to require that you use rn?
If it is, I can add this information to the mail function docs.
--
-
[2001-03-20 02:42:22] [EMAIL PROTECTED]
script example:
--
---
?php
$returnvar=false;
$mailto=[EMAIL PROTECTED];
$mailsubject=cc test;
$mailmessage=message content;
$mailHeader=cc:[EMAIL PROTECTED];
$returnvar=mail($mailto,$mailsubject,$mailmessage,$mailHeader);
?
html
body
the mail was sent?
?php
echo brreturnvar= $returnvarbr;
?
/body
/html
--
---
The above does not send the carbon copy.
The pdf manual says:
--
$headers .= cc:[EMAIL PROTECTED]; // CC to
$headers .= bcc:[EMAIL PROTECTED], [EMAIL PROTECTED]; // BCCs
to
/* and now mail it */
mail($recipient, $subject, $message, $headers);
--
-
That does not work since Win32 sendmail.c looks for case sensitve Cc:
sendmail.c also does not look for bcc:
Also you must have rn not just n.
I think the problem is here in win32 sendmail.c :
if (headers (pos1 = strstr(headers, Cc:))) {
pos2 = strstr(pos1, rn);
tempMailTo = estrndup(pos1, pos2-pos1);
--
-
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=9859edit=2
--
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]
--
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]
[PHP-DEV] Bug #11010 Updated: current cvs cannot configure
ID: 11010 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: *Install and Config Operating system: Linux glibc 2.1 PHP Version: 4.0 Latest CVS (2001-05-22) Description: current cvs cannot configure freshmeat on autoconf: Changes: This version includes 2 years of accumulated improvements and bugfixes. While almost every line of code has been touched since version 2.13, Autoconf 2.50 aims to be backward compatible for well-written configure.in scripts. i removed 2.50 and put back 2.13 and everything is ok now i've looked further but they do not define well-written... Previous Comments: --- [2001-05-22 02:34:54] [EMAIL PROTECTED] after upgrading libtool to 1.4 i have upgraded automake and autoconf to latest stable versions, here is the result: buildconf: checking installation... buildconf: autoconf version 2.50 (ok) build/buildcheck.sh: test: 4-p1: integer expression expected buildconf: automake version 1.4-p1 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure ./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion ./aclocal.m4:452: PHP_SUBST is expanded from... ./aclocal.m4:904: the top level rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: error: shell error while sourcing /tmp/ah26273/traces.sh in build/buildcheck.sh: first problem - automake version is 1.4-p1 and this check fails: IFS=.; set $am_version; IFS=' ' if test $1 = 1 -a $2 -lt 4 || test $1 -lt 1; then fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:25:01 @@ -40,7 +40,7 @@ fi # automake 1.4 or newer -am_version=`automake --version 2/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* *$//'` +am_version=`automake --version 2/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* +*$//' -e 's/-/./'` if test $am_version = ; then echo buildconf: automake not found. echoYou need automake version 1.4 or newer installed second problem - after double checking for libtool, $libtool is set to `which libtool` or `which glibtool`. in the check if libtool and automake are in the same path again which is used that is incorrect because which /bin/libtool founds nothing. fix: Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.8 diff -u -r1.8 buildcheck.sh --- build/buildcheck.sh 2001/05/06 18:51:21 1.8 +++ build/buildcheck.sh 2001/05/22 00:30:21 @@ -81,7 +81,7 @@ fi am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'` -lt_prefix=`which $libtool | sed -e 's#/[^/]*/[^/]*$##'` +lt_prefix=`echo $libtool | sed -e 's#/[^/]*/[^/]*$##'` if test $am_prefix != $lt_prefix; then echo WARNING: automake and libtool are installed in different echo directories. This may cause aclocal to fail. i'd update this bug when i find what else is going wrong --- Full Bug description available at: http://bugs.php.net/?id=11010 -- 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]
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
One thing I'd like to see is a utility which could check a source directory and warn about obviously deprecated / insecure / inefficient things. It'd make life easier for that hypothetical ISP admin with a large pile of code which has been haphazardly maintained for years. hey, guys, how do you imagine an isp admin changing hosted code in order to upgrade php to a newer incompatible version? this is a dream - if isps are not sure it will work without changes, they will never upgrade. if they upgrade and thousands of sites stop working many people will _really_hate_ php lets say i am the client and my isp decides to upgrade - they change my .php files so they now work with the latest php version, tommorow i login and upload my newer version and everything stops working, yes everything because one of the files included everywhere uses a deprecated construct and bloats with a syntax error... breaking backward compatibility in php is not a good thing - it even cannot be compared to apache 1.2.x differences to 1.3.x ones. for isps the webserver is their responsibility but php code is user's. moving from apache 1.2.x to 1.3.x for a server with hundreds of hosted sites is a piece of cake compared to upgrading from php3 to php4 - this is the reason many isps do not upgrade and will not b. -- 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]
Fw: [PHP-DEV] 4.0.6
- Original Message - From: Boian Bonev [EMAIL PROTECTED] To: Dave Jones [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 6:29 PM Subject: Re: [PHP-DEV] 4.0.6 hi, And also line number don't get incremented if there are no line ends, so all syntax errors are reported as being on line 1. The issue might have never come up if the code used r mode for opens rather that rb, since the file are 'text' files. On platforms that don't used embedded newline characters as the record delimiters, the implementation of fread is responsible for mapping the underlying file format to cannonical form (i.e. \n's delimiting lines). you are partially correct - if we have only 'native' files - yes this is the case. but imagine tons of downloaded code, parts of it originating from *nix others from windows, and parts of them edited so all the three possible combinations are used. perhapse you know that most editors convert line endings only for edited lines not for the whole file. now the task of correctly counting line numbers is not that easy. neighter file conversion is. of course some editors pretend to be that clever to interprete all the three formats - something like greedy eating \n\r|\n|\r in this order... b. forgot to say that php must flawlessly interprete all the combinations provided that it is a platform independant language and never rely on os specific stuff - win php source must work on unix as unix php source on windows... -- 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]
Re: [PHP-DEV] 4.0.6
Note that there was no such problem with PHP 4.0.4pl1 and earlier. That's very odd, as PHP never considered \r alone to be a linefeed... it is not that odd because it may have treated it like whitespace - imagine a long line script. now it may treat it not as whitespace and hence the problem there is no big difference between whitespace and newline(s) in php, is it? b. -- 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]
Re: [PHP-DEV] mailparse extension
I would like to put my mailparse (As seen on zend.com weekly summary) extension into CVS; shall I just check it into php4/ext? i'd also like to see this one released in php. :) b. -- 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]
Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)
hi, That only really works for forking webservers, does it not? Another alternative would be to use microseconds... Yeah we could use microseconds but are they available on all platforms? In any case, on non-forking servers we can use thread id. if it is a threading server then why not make crypt's salt seed global... at least there is no wat to generate two equal salts with it. btw, in real life when one needs security he will generate the salt himself b. -- 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]
Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting
i forgot to say that maybe we shall add two more bugs from this one - - a feature request for not allowing nonsense settings like the mentioned in the list - i don't know if is it a good idea post file upload to generate a warning when limit is exceeded b. - Original Message - From: Hartmut Holzgraefe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 5:59 PM Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting [EMAIL PROTECTED] wrote: Please take into account that the processing of post data happens _before_ your call to ini_set. Thus your new limit value has no effect to the upload and succeeds (of course) after the upload is rejected. maybe we should think about a way to mark all ini settings like these and generate warnings when ini_set is used at runtime to change them -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] -- 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]
Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting
sure. i guess at least about egpcs handling, arg separator, magic quotes, perhapse some session options, register_globals, safe_mode. lets make a list - this can be easily fixed. :) b. - Original Message - From: Hartmut Holzgraefe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 5:59 PM Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting [EMAIL PROTECTED] wrote: Please take into account that the processing of post data happens _before_ your call to ini_set. Thus your new limit value has no effect to the upload and succeeds (of course) after the upload is rejected. maybe we should think about a way to mark all ini settings like these and generate warnings when ini_set is used at runtime to change them -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] -- 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]
Re: [PHP-DEV] RE: 4.0.5: Merge Request
hi, Maybe something like this 1. Any problems which result in seg faults/gpfs are show stoppers, code doesnt go out till its fixed, or feature is removed till we can fix it. this is not correct (in general :) - there are segfaults in experimental stuff that do not imply exploits, are no security risk and are just a new/unused feature that does not work as expected. it IS ok to release with such a segfault. an example: bbonev@orange:~$ echo ? \$a=1 ? | php -a Interactive mode enabled X-Powered-By: PHP/4.0.5RC6 Content-type: text/html Segmentation fault see bug id 8621 i think commonsense shall be used to judge what is showstopper and what is not :) this one definitely is not b. -- 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]
Re: [PHP-DEV] request
You could have two classes both defining an innocent method toString(), for example, and with your suggestion, inheriting from those classes would cause a hard error? Why would "first encountered" definition change? If anything that affected how classes were ordered changed, if the classes were renamed, if the class definitions changed... first occurence means the first occurence in the inheritance list. then it is important how you order the class names when you inherit them, not when they got defined. b. -- 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]
Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
Perhaps optionally disabled.. --without-cgi? I would go for optionally on, I really dont want to build both the apache module (p.e.) AND the CGi at the same time. For QA testing this is fine, but not for production servers. If you want to use the PEAR tools, you need the CGI version. These are definitely intended for production servers. i'd also preffer to have both versions - on all of my production servers i do install both apache module and cgi version. the latter i use for cron jobs, background processing and whatsoever tasks that need to do something outside the web. so in my opinion both sapi module and cgi will be a fine default. one more 'little' binary in /usr/local/bin would harm noone. also some isp configurations with several sapi setups on the same machine would benefit easier maintenance with this option. of course a way to disable it is ok but since PEAR needs the cgi ver to be able to fetch modules and etc the default should be 'enabled'. b. -- 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]
Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
i'd also preffer to have both versions - on all of my production servers i do install both apache module and cgi version. the latter i use for cron jobs, background processing and whatsoever tasks that need to do something outside the web. so in my opinion both sapi module and cgi will be a fine default. one more 'little' binary in /usr/local/bin would harm noone. also some isp configurations with several sapi setups on the same machine would benefit easier maintenance with this option. of course a way to disable it is ok but since PEAR needs the cgi ver to be able to fetch modules and etc the default should be 'enabled'. Also it make sense to separate all but SAPI modules into shared library to which SAPI module is linked dynamically. Then SAPI module binaries will all share one code. indeed this is only one more step in the build process - make the core php lib then link to all the sapi modules on the configure command line and install them one by one. you did not mean dll/so right? because the base library must be a static one and then the sapi modules themselves may be either dynamic or static... b. -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: changes
hi, i am speaking for the main branch. if the community decides that adding a function declaration can break anything then just do not commit this into 4.0.5 :) as far as i have seen many major changes have been made to 4.0.5. anyway it will work both ways except that calling the function with wrong args wont issue a warning (at least for gcc - i have seen compilers pretending to be more strict than needed and giving errors in such a condition). btw. a month ago Rasmus asured me that the change is in cvs but perhapse he has commited it to the wrong branch. b. the idea is that it would be better if the line above is included in exec.h... of course it works without it but at least i am not happy with it this way. You would be perfectly right, if we would be dealing with the main branch of CVS. In the case of the release branch, many people consider changes to be "bad" per default. So, if we can release working code without applying any changes, we usually prefer that route. -- 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]
Re: [PHP-DEV] RE: ; arg seperator
hi, There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. I'd be completely against removing the concept of magic_quotes altogether. We can discuss changing the default, but for someone writing simple sql pages, it is extremely handy to have PHP deal with escaping stuff for you so you don't have a bunch of addslashes() calls everywhere. perhapse all those topics must be decided on a statistical basis. lets name it: count of boxes broken if arg_separator is ';' count of boxes that dont care about arg_separator default count of boxes that need arg_separator to be ';' count of boxes relying on magic_quotes_gpc count of boxes that dont care about magic_quotes_gpc count of boxes that need magic_quotes_gpc set to off the decision must break least possible count of php setups when they upgrade to the newest version. it would be a disaster for people who have a running server/site and everything or even worse something somewhere goes wrong. not to speak about hosting providers who upgrade farms of servers. their users will have to track problems that occur depending on the input data and mostly in rare cases. i think this will be a negative impact on many sites making people reluctant to upgrade to newer php versions. php4.0.5 is not that better that 4.0.x compared to the difference between 3 and 4 to afford to break existing functionality... b. -- 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]
Re: [PHP-DEV] efree/emalloc in sapi
Generally, the emalloc should be working all the way since start_memory_manager was called - which means, from engine startup. The "request cleanup" (freeing all non-persistent memory blocks) happens on shutdown_memory_manager, which is called from php_request_shutdown, after calling request shutdown routines for all modules and extensions, including SAPI request shutdown. Giving second look on what I wrote, you code (from what I got from your description) generally should be safe to use emalloc... Maybe you have some other problem there? first to tell you what exactly am i doing - a sapi module for a radius server... (i have posted a note a while ago here) the thing is not threaded and there are several processes calling external stuff. i have replaced the exec call to process php files natively. my future plan is to make some checks on file extension and process it both ways but this is not important for my problem. generally the radius server processes two types of requests: - login (query) that goes in a single new process which dies afterwards - accounting - start/alive and stop that is handled sequentially in a single process that never exits my first code used emalloc/efree in the following places: sapi_startup... php_module_startup... * some emalloc php_request_startup php_execute_script php_request_shutdown * some efree php_module_shutdown sapi_shutdown this works fine if called one time (login works ok). if an acct request comes in - the first one works fine and the next one segfaults or infinitely loops in libc's free. the whole thing works fine again if i remove the efree calls. (with a small leak but i am not sure if this isn't some cache) here i conclude that the request_shutdown call is freeing my memory and when i free it again there is a memory mess. after replacing emalloc/efree with malloc/free the code works (with a small leak but i am not sure if this isn't some cache) i know that if i repeatedly execute php scripts from a single process it is better to sapi/module startup once then execute_script and at exit sapi/module shutdown. but i think it shall work both ways only with a performance penalty in my case... b. -- 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]
Re: [PHP-DEV] efree/emalloc in sapi
hi, i know. the problem is i have used the thttpd sapi module as a sample and it is supposed to be stable. i have solved my problem by using plain malloc/free - my reason to share this experience is that there may be a leak or segfault in some of the sapi modules. i haven't found neighter bug nor leak still but it is possible. can someone tell me the exact places where emalloced memory begins to be tracked and where the leaks are efreed? b. BB i have hit on this issue while trying to make a sapi module. my BB problem was that memory emalloc-ed _before_ the request got BB efree-ed by the memory manager after the request and when i BB efree it afterwards a total memory mess occurs (sigsegv, BB infinite loop in libc free or something more nasty)... You probably should use plain old malloc when you not inside the request. -- 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]
Re: [PHP-DEV] Leaking references
hi, I won't be holding my breath for it. That's the basic property of reference-counting, so it's not easy to make it behave differently. Anyway, unless you have very-long-running very-memory-greedy scripts, these leaks shouldn't bother you - Zend memory manager cleans them up on every request. i have hit on this issue while trying to make a sapi module. my problem was that memory emalloc-ed _before_ the request got efree-ed by the memory manager after the request and when i efree it afterwards a total memory mess occurs (sigsegv, infinite loop in libc free or something more nasty)... is there more info on exactly where emalloc tracks memory and when frees all unfreed blocks in the process of sapi_startup php_module_startup // memory alloced here gets freed by request_shutdown (i suppose) php_request_startup php_execute_script php_request_shutdown php_module_shutdown sapi_shutdown or i am missing something important? b. -- 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]
Fw: [PHP-DEV] feature request
oops, forgot the list.
i think no lang extension is needed. here is my reason - you can very easy
test for isset, what about !isset? then the condition will be or not and and
all the thing becomes messy.
b.
- Original Message -
From: "Boian Bonev" [EMAIL PROTECTED]
To: "Gavin Sherry" [EMAIL PROTECTED]; "Cameron" [EMAIL PROTECTED]
Sent: Monday, March 19, 2001 2:23 PM
Subject: Re: [PHP-DEV] feature request
hi,
better write you own checker in php... and implement and/or...
here is a sample :-)))
?
function isset_and() {
$numargs=func_num_args();
$tt=func_get_arg($i);
$res=isset($tt);
for ($i=1;$i$numargs;$i++) {
$tt=func_get_arg($i);
echo "$tt\n";
$res=isset($tt);
}
return $res;
}
$a='asda';
$b='asa';
echo isset_and($a,$b,$c);
echo "\n";
$c='asa';
echo isset_and($a,$b,$c);
?
--
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]
[PHP-DEV] php sapi 4 radiusd
hi, today i made something crazy - even i didn't believe it will do but i made it through and i want to hear your opinion... i am getting pissed from writing c code in one of our client's radius servers and decided to ease the whole process, put it under control and make the auth/account logic more maintainable... i have started a sapi module for the xtradius server (www.xtradius.com) and got something near working copy. the concept is clean - radiusd passes envp style attributes to the sapi module, then all of them translate into a http get like request. script output is parsed by the radius server against its disctionary. xtradius forks on requests so there is no thread safety stuff. the only problem is how to integrate into its code - there is neighter api nor modules. a patch file will do but only for the current and near versions. i could use perl or cmdline php but with the sapi i save one fork per request, one exec and php image loading... still not sure, b. -- 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]
Re: [PHP-DEV] X-Powered-by
hi,
header("Foo: bar\r\n");
Get rid of that CRLF and it should work.
this is an idea. what about if header stripped all \n \r? i cant see a
reasonable use of \n in a header line...
b.
--
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]
Re: [PHP-DEV] popen() spans 100 processes
Encountered 100 spanned cmd.exe + php.exe using win32 CGI, this does not happen using apachemod, my task manager was open by accident, otherwise I would not have noticed this... sounds like the second php 'detects' CGI mode, reads script name from environment vars then executes the same script again and again? b. -- 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]
Re: [PHP-DEV] Rsync and CVS
hi, i'd suggest to make things simpler - just plain pre-generated html with the notes part. name it after TOPIC and include it in the proper place. the generator script may run as cron job. there is only one problem - to prevent rsync client from getting a semi-generated copy. this can be achieved like: or better - why not generate html upon comment add and use the html on the main site also? The reason the HTML is not pregenerated, is so that we can change the formatting etc on the fly. Perhaps according to a "max comments per page", or "look and feel" parameters. The CPU load in formatting comments is pretty insignificant, especially compared to the other things it does at the same time. keep the stuff in the db like now. when you change design or alignment or something just generate again... thus loose no flexibility and make mirroring flawless. the code that generates the html is already written, the whole thing is just a small rearrange. why keep the file includes on the main site? just to have exact copies - no different versions, no if ($mirror)... about cpu you are partly right (cpu power is cheep these days). but we can't compare text include/readfile/somthing with db query/fetch/etc right? why not use the more performant one when nothing is lost. There might be some arguements for caching the comments in the filesystem (on www.php.net), but the gains are probably not worth the hassle, IMHO. if mirroring requires it - why not use it in both places and keep code simple and maintainable? b. -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied
Are you sure you're using the php4.0.4pl1 source tarball from www.php.net?? I just checked that file and it doesn't have any #line directives in it. [2001-03-02 14:04:44] [EMAIL PROTECTED] the following is the second line of the file [path-to-php]/ext/standard/url_scanner_ex.c : #line 1 "/home/sas/src/php4/ext/standard/url_scanner_ex.re" look in url_scanner_ex.c not in url_scanner_ex.re. at least in latest cvs there are #line-s. my gcc does like them no matter there is no home/sas - perhapse rick's is old or something... non-gcc compilers may complain badly on these also these are put automaticaly by re2c. it is invoked with full path in make file, so it generates #line-s with full path. non-developers really do not need these #line directives and developer will recreate them by remaking c from re. so the best solution is to remove #line-s from the c file in cvs. b. -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied
Yes, in CVS those directives can be found. But not in CVS snapshots or in releases. So this shouldn't be a problem if people are using those. these are put automaticaly by re2c. it is invoked with full path in make file, so it generates #line-s with full path. non-developers really do not need these #line directives and developer will recreate them by remaking c from re. so the best solution is to remove #line-s from the c file in cvs. I don't think it's necessary. If someone is getting PHP from CVS they just have to run ./genfiles to get rid of the #line directives. hmm. i didn't know this eighter. then everything is ok :) Maybe this should be mentioned at http://bugs.php.net/anoncvs.php page? (why would some non-developer get his PHP 4 from CVS anyway? :) there is at least one reason - to compile with a new feature that is not released still. it is not recommended but i know about people doing this... b. -- 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]
Re: [PHP-DEV] RE: PHP 4.0 Bug #9529 Updated: php4_module is garbled
did you rm httpd make or make clean all install? b. - Original Message - From: "Mike Gibbons" [EMAIL PROTECTED] To: "Bug Database" [EMAIL PROTECTED] Sent: Sunday, March 04, 2001 3:17 AM Subject: [PHP-DEV] RE: PHP 4.0 Bug #9529 Updated: php4_module is garbled ldd httpd libm.so.6 = /lib/libm.so.6 (0x40017000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40034000) libdb.so.3 = /lib/libdb.so.3 (0x40061000) libdl.so.2 = /lib/libdl.so.2 (0x4009b000) libc.so.6 = /lib/libc.so.6 (0x4009e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) -- 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]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
hi, [i move this to php-dev where is the right place IMHO] indeed the library is used by me, you and perhapse two more people (two have asked how to get/make/use it). my code is not problematic to change - i am using different servers for test and production and i can change it with not more than a minute downtime. not to mention that i can build version with aliases, change the code live and reinstall version without the aliases... tell us how hard it is to change your code... now is the most appropriate time to agree on a certain naming convention. there is a huge discussion about this on php-dev and my opinion is that once released things must not be changed. it is better two or four of us change our code and achieve consistency than release this and tomorrow make aliases and stuff... both ways look ok to me - vpopmail_name from lib and vpopmail_name from lib made readable with _ the api is not something like isalpha and noone is stuck to a name so both conventions are acceptable now. btw. i have started an xml doc - would you help me with language stuff - english is not native for me and i do not feel confident when writing non-code... b. - Original Message - From: "David Croft" [EMAIL PROTECTED] To: "Andrei Zmievski" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 11:02 PM Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h On Tue, 16 Jan 2001, Andrei Zmievski wrote: PHP_FE(vpopmail_passwd, NULL) PHP_FE(vpopmail_setuserquota, NULL) [snip] Didn't we agree to put underscores between words in function names, i.e. vpopmail_del_user? At the expense of losing compatability with the library's existing naming convention? David -- PHP CVS 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] -- 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]
Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming
Just +1 :) - Original Message - From: "Stanislav Malyshev" [EMAIL PROTECTED] To: "Ron Chmara" [EMAIL PROTECTED] Cc: "PHP Development" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 1:47 PM Subject: Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming RC It's more legible for the same reason that it's easier (and RC faster) to read "one two three" than "onetwothree". The human RC mind can easily tokenize at the appropriate places, when it has RC a token. Without a token, the string is much harder to parse. For me, "isalpha" is single token. That's the name, much like Johnson or Chandrabharmata. RC There's several, in order of use: ldap_connect, ldap_bind, ldap_search. RC Without looking in the manual, I _don't_ have to guess if it's ldap_search RC or ldapsearch. Which is my entire point. I know the ldap functions were Exactly. Because you don't know the "search" part, wondering on underscore is useless. That's my point. I repeat it once more, to be clear: Functions that have "well known" names should not be touched. That includes fopen (not open_file, neither file_open or filesystem_open_file, thankyouverymuch), isaplha, ImageGif, etc., etc. Functions that do not have established names (like most third-party libraries) can be named by any standard that feels warm on your heart, I have no objection on this. RC I didn't check a manual. Ldap functions aren't named in a mixed fashion RC of word_wordword and word_word_word. They follow the *most common* PHP RC syntax of using word_word_word. Don't try to make me believe you remember all the "non-underscore" part of all functions by hard and your only problem is knowing where's the underscore. RC To stop confusing the *language*, as a whole, we should be doing this with RC some consistency, so we're not confusing people as they try to learn new RC function names. They shouldn't have to guess, or read the manual, just RC to figure out the "proper spacing" in invoking it. That's not "confusing". That's "remaining in touch with the rest of the known world". I do not want function to open file be "filesystem_open_file". I want my old trusty fopen. It served me well for years. -- 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]
Re: [PHP-DEV] anyone with m4 knowledge - [PHP-DEV] please patch for dbmaker
hi, this is not m4 but /bin/sh stuff... afaik [[ is bash specific boolean test. so the patch _seems_ to be correct... b. - Original Message - From: "Andr Langhorst" [EMAIL PROTECTED] To: "PHP Development" [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 5:31 AM Subject: [PHP-DEV] anyone with m4 knowledge - [PHP-DEV] please patch for dbmaker could anyone with basic m4 knowledge look into this, this should be a matter of minutes then I guess. andr -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.net * -- 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] -- 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]
Re: [PHP-DEV] anyone with m4 knowledge - [PHP-DEV] please patch for dbmaker
forgot to say that in case of [[ the test word is not needed - [[ is a test itself: if [[ -x somefile ]]; . if test -x somefile; b. - Original Message - From: "Boian Bonev" [EMAIL PROTECTED] To: "Andr Langhorst" [EMAIL PROTECTED]; "PHP Development" [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 5:40 AM Subject: Re: [PHP-DEV] anyone with m4 knowledge - [PHP-DEV] please patch for dbmaker hi, this is not m4 but /bin/sh stuff... afaik [[ is bash specific boolean test. so the patch _seems_ to be correct... b. - Original Message - From: "Andr Langhorst" [EMAIL PROTECTED] To: "PHP Development" [EMAIL PROTECTED] Sent: Thursday, February 22, 2001 5:31 AM Subject: [PHP-DEV] anyone with m4 knowledge - [PHP-DEV] please patch for dbmaker could anyone with basic m4 knowledge look into this, this should be a matter of minutes then I guess. andr -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.net * -- -- -- 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] -- 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] -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #9177 Updated: crypt problems with openssl
Well, I think it's just the link order of libraries. ie. the openssl lib should be before libc..but is that even possible? Or just add another entry for libc after ssl? Might be possible to do some kludge with the link order, I would prefer that OpenSSL changed a bit though, I'll probably have to go nag them again. OpenLDAP needs this to be fixed as well, and I'm sure there are other programs with the same problem. it will not be possible for libc. i have solved similar problem with two conflicting libs thus: gcc -o something -l lib-i-want-to-discard-conflicting-foo ...path/lib-with-preffered-conflicting-foo.so[mething] objects... gnu ld looks in objects tagged for linkage and then in libraries. afaik libc is the last place ld will process and there is no chance to fool it. the best solution is to fix openssl. b. -- 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]
[PHP-DEV] PHP 4.0 Bug #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work
ID: 9231 User Update by: [EMAIL PROTECTED] Status: Assigned Bug Type: Output Control Description: when usign ob_gzhandler HTTP HEAD does not work yep. both seem to be apache SAPI module problem related to ob in general (at least i suppose so) Previous Comments: --- [2001-02-19 23:03:00] [EMAIL PROTECTED] similar to Bug id #9031 --- [2001-02-17 11:51:19] [EMAIL PROTECTED] reopened --- [2001-02-17 11:50:18] [EMAIL PROTECTED] HTTP-1.0 and HTTP/1.0 are just the same for apache this bug report says that ob_gzhandler crashes HEAD requests when php is an apache module --- [2001-02-14 12:25:12] [EMAIL PROTECTED] shouldn't it reaad HEAD / HTTP/1.0 bogus --- [2001-02-12 15:05:20] [EMAIL PROTECTED] php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9231 -- 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]
[PHP-DEV] PHP 4.0 Bug #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work
ID: 9231 User Update by: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Description: when usign ob_gzhandler HTTP HEAD does not work HTTP-1.0 and HTTP/1.0 are just the same for apache this bug report says that ob_gzhandler crashes HEAD requests when php is an apache module Previous Comments: --- [2001-02-14 12:25:12] [EMAIL PROTECTED] shouldn't it reaad HEAD / HTTP/1.0 bogus --- [2001-02-12 15:05:20] [EMAIL PROTECTED] php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. --- Full Bug description available at: http://bugs.php.net/?id=9231 -- 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]
[PHP-DEV] PHP 4.0 Bug #9231: when usign ob_gzhandler HTTP HEAD does not work
From: [EMAIL PROTECTED] Operating system: Linux glibc 2.1 PHP version: 4.0 Latest CVS (12/02/2001) PHP Bug Type: Output Control Bug description: when usign ob_gzhandler HTTP HEAD does not work php.ini: output_handler = ob_gzhandler tests: a plain html request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 HTTP/1.1 200 OK Date: Mon, 12 Feb 2001 19:57:47 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT ETag: "ac04-1f6-3a2b95af" Accept-Ranges: bytes Content-Length: 502 Connection: close Content-Type: text/html Connection closed by foreign host. php script request: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. HEAD / HTTP-1.0 host: mail.bonev.com same php script, but now GET instead of HEAD: root@orange:~# telnet 0 80 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. GET / HTTP/1.0 host: mail.bonev.com HTTP/1.1 302 Found Date: Mon, 12 Feb 2001 19:57:22 GMT Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev X-Powered-By: PHP/4.0.5-dev location: /6bcf63364235c745643078ff1e0df2d6/ Connection: close Content-Type: text/html Connection closed by foreign host. -- Edit Bug report at: http://bugs.php.net/?id=9231edit=1 -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault
hi,
indeed it is theoretically impossible to track this :)
implement a recursive alrorithm for something e.g.:
function foo($n) { // calc $n!
if ($n=1)
return $n;
else
return foo($n-1)*$n;
}
now tell me if it is infinite or finite? ;-) this is a verification and
cannot be solved runtime.
the best thing that can be done is to set a stack limit (php function
call
level) to something reasonable and thus avoid the segfault.
This gives a problem itself, how many levels before the stack is full? Not
every function call has the same memory footprint, so you can't tell after
how many levels the stack is full.
of course. but it is better to set something like 1000(or 100) and be
sure that a malicious user cannot exploit it. as far as i remember php local
vars are emalloc-ed and are not on the stack. so there is an average value
like 64(or 640) bytes per stack frame or something...
b.
--
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]
Re: [PHP-DEV] The library yes/lib does not exist
hi, i've seen the same really soon and could track it: Cool, I looked further down the specific config.m4 and it appears that the zlib check was copied and not modified correctly. Fix committed. 10x :)) it was annoying and hard to track because i have 10+ --with- configure options. another thing - i have noticed that when i issue configure some setup make configure another setup make in phpinfo i get some setup as config options. also not all of the stuff is rebuilt properly. it is not a good idea to rebuild all the stuff. currently less than needed is rebuilt. especially when i remove modules - when i add everything seems fine. i know i can make clean or even distclean but it is not nice... b. -- 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]
[PHP-DEV] ext/standard/exec.h
hi, can someone commit the followingchange: Index: ext/standard/exec.h===RCS file: /repository/php4/ext/standard/exec.h,vretrieving revision 1.6diff -u -r1.6 exec.h--- ext/standard/exec.h 2000/09/05 16:55:32 1.6+++ ext/standard/exec.h 2001/02/07 17:55:20@@ -29,4 +29,6 @@PHP_FUNCTION(shell_exec);char *php_escape_shell_cmd(char *);+int php_Exec(int type, char *cmd, pval *array, pval *return_value);+#endif /* EXEC_H */ b.
Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault
hi,
indeed it is theoretically impossible to track this :)
implement a recursive alrorithm for something e.g.:
function foo($n) { // calc $n!
if ($n=1)
return $n;
else
return foo($n-1)*$n;
}
now tell me if it is infinite or finite? ;-) this is a verification and
cannot be solved runtime.
the best thing that can be done is to set a stack limit (php function call
level) to something reasonable and thus avoid the segfault.
b.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 07, 2001 12:31 AM
Subject: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite
function calls causes seg fault
ID: 9136
Updated by: waldschrott
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproduceable crash
Assigned To: waldschrott
Comments:
and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full
remember php has to remember each and every function call it
did...
a()
b()
a()
b()
if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again
any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely
Previous Comments:
--
-
[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on the
php-dev list, it wont be implemented to guard for this, because of the high
performance impact.
--
-
[2001-02-06 17:18:03] [EMAIL PROTECTED]
---
%
function a () {
b();
}
function b () {
a();
}
a();
%
h1done/h1
-
The simple script above causes a seg fault. If you need more info on
configuration etc please mail me. We made this simple example from a more
compilcated instance. This bug was also present in 4.0.3pl1, we upgraded to
try and stop the seg fault...
thanks!
--
-
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=9136edit=2
--
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]
--
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]
Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
hi, i'd disagree on this - imagine you have a webserver with reasonable load and 99.9% of php page requests use max 10mb ram. you have 1% that use 100mb ram. then it not a good idea to upgrade to 1g ram just for these 0.1% since each httpd process will hold 100mb ram after certain time (the 0.1% will spread on all httpd processes) on the other side getting and returning ram to the system is not a fast thing and should be avoided. most common solution is to tell the memory cache how much ram to held. or preset it at compile time. i see that my most loaded system (most complex scripts) uses about 10m per process. b. Seems to me like it would be a lot easier just to add more RAM. $89 for 256M these days. RAM is cheap. That is what we are doing now. We have it at 5. Any higher and we are running out. There is only 128MB of RAM in our machine. I am considering switching to CGI PHP just to eliviate this problem. Of course, that sucks. Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory hungry script" happens from time to time and there's no chance to prevent httpd processes from keeping memory (which is not used again in most cases). Maybe it is not a problem for you, but it is for us. A quick fix would be to set your MaxRequestsPerChild to a lower value. -- 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]
Re: [PHP-DEV] EXTENSIONS file refresh..
hi, Another thing: Would it be good idea to have the EXPERIMENTAL text in configure help for such options? This could be automated in the buildconf ie. it could check if the EXPERIMENTAL is in the extension's dir and adds the text before/after the option in the help display..? And maybe even a note after configure that there are extensions configured in which are considered experimental thus those might not work as expected. Good idea! Anyone else agreeing with us? :) of course. most people don't really bother to read even the configure output, i suppose 10% (or less) look into ext/extdir to find readme/experimental. another idea is to have an extension txt help file shown by configure with something like --help-extname or so. anyway these are bells and whistles - good to have but can live without. b. pp. Jani, sorry for double mailing but forgot to click reply-all :( -- 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]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
hi,
i do not like this too but this are the names exported by vpopmail api.
this can be changed very easy. i am currently waiting for reply from David
about what the php api support, what not and how...
b.
- Original Message -
From: "Andrei Zmievski" [EMAIL PROTECTED]
To: "David Croft" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 16, 2001 4:42 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
On Sun, 14 Jan 2001, David Croft wrote:
function_entry vpopmail_functions[] = {
PHP_FE(vpopmail_auth_user, NULL)
PHP_FE(vpopmail_adddomain, NULL)
PHP_FE(vpopmail_deldomain, NULL)
PHP_FE(vpopmail_adduser, NULL)
PHP_FE(vpopmail_deluser, NULL)
PHP_FE(vpopmail_passwd, NULL)
PHP_FE(vpopmail_setuserquota, NULL)
{NULL, NULL, NULL}
};
Didn't we agree to put underscores between words in function names, i.e.
vpopmail_del_user?
-Andrei
* Life may be expensive, but it includes an annual free trip around the
sun. *
--
PHP CVS 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]
--
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]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
sorry for broken english.
I just wanted to say that vpopmail's api uses function naming convention
which is incomatible with php style. This is the reason to name php
functions after vpopmail api, prefixing them with vpopmail_. We can fix this
easy.
b.
- Original Message -
From: "Boian Bonev" [EMAIL PROTECTED]
To: "Andrei Zmievski" [EMAIL PROTECTED]; "PHP Development"
[EMAIL PROTECTED]; "David Croft" [EMAIL PROTECTED]
Sent: Wednesday, January 17, 2001 5:03 PM
Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
hi,
i do not like this too but this are the names exported by vpopmail api.
this can be changed very easy. i am currently waiting for reply from David
about what the php api support, what not and how...
b.
- Original Message -
From: "Andrei Zmievski" [EMAIL PROTECTED]
To: "David Croft" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 16, 2001 4:42 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
On Sun, 14 Jan 2001, David Croft wrote:
function_entry vpopmail_functions[] = {
PHP_FE(vpopmail_auth_user, NULL)
PHP_FE(vpopmail_adddomain, NULL)
PHP_FE(vpopmail_deldomain, NULL)
PHP_FE(vpopmail_adduser, NULL)
PHP_FE(vpopmail_deluser, NULL)
PHP_FE(vpopmail_passwd, NULL)
PHP_FE(vpopmail_setuserquota, NULL)
{NULL, NULL, NULL}
};
Didn't we agree to put underscores between words in function names, i.e.
vpopmail_del_user?
-Andrei
* Life may be expensive, but it includes an annual free trip around the
sun. *
--
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]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
hi, sure. can i ask you another style question? snips form a config.m4 file: --- AC_MSG_RESULT(found in $VPOPMAIL_LIB_DIR) --- --- AC_MSG_CHECKING(for vpopmail install directory) ... code follows... AC_MSG_RESULT($VPOPMAIL_DIR) --- i wonder which one is preferable to use. b. - Original Message - I just wanted to say that vpopmail's api uses function naming convention which is incomatible with php style. This is the reason to name php functions after vpopmail api, prefixing them with vpopmail_. We can fix this easy. The PHP interface to vpopmail does not have to depend on the naming conventions used by the vpopmail library. -- 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]
Re: [PHP-DEV] cgi+dso
hi, i'd appreciate this feature very much (perhaps many others also will)... in most of my setups (about 10 servers) i need to compile both versions and keeping apache module and command line php setup in sync is somewhat hard and sometimes problematic ;) b. I was wondering if there's currently any way to compile up both the CGI version, and the Apache DSO in a single compile? Looking at the autoconf stuff implies that there isn't, since there's a single PHP_SAPI variable that defaults to cgi. Is there any interest in this changing? With the rise of PEAR, it's more and more important to provide a binary, and I'd like to install it by default on the OpenBSD port. However, it seems a bit wasteful to require two compilations, when the vast majority of what is compiling stays the same. -- 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]
[PHP-DEV] module to interface vpopmail
hi, i am using vpopmail for a large site with many users signing in or changing quotas, etc. for those who are not familiar to vpopmail - it is free qmail addon to implement easy virtual domain management - more info on http://www.inter7.com/vpopmail/. the site is wholy php based. for more than an year i were using interafce module written in php that exec'd suid ~vpopmail/bin/* for various operations and emulating vpopmail api to php. since in my setup (and i suppose in most large scale ones) php is built into apache thus gaining performance over cgi exec and etc., i have decided to make a php wrapper module for the vpopmail api providing the functionality through 'native' php calls. part of vpopmail functionality does not require suid root. only vpopmail and apache must be run as the same user. this is not a big pain - only domain management requires qmail interaction and must be implemented as external process exec. i think the stuff will be of high interest to all vpopmail users but i cannot estimate their volume. i am writing this message to see the interest in this stuff and also get ideas about the way php modules may be distributed... b. -- 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]
