Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?
On Tue, Mar 25, 2003 at 01:50:17PM +, Matt Flaherty wrote: Hi, I have a question for the authors of the mysql extension. I'm sure you gentlemen are very busy, but I'd appreciate your insight if you can spare a moment. I'm developing a stand-alone php application running in an infinite loop from the command line interface. A mysql database is polled continually for new rows to deal with. The same query is executed several times in one second. I've noticed that whether or not a query resource is freed the next query identifier returned from mysql_query() is ++ the last one. I'm sure this is by design and governed by the mysql driver. Naturally I'm concerned about integer overflow when the the application has been running uninterrupted for a very long time. I don't think I can wait around while a test script runs to see what happens after 4,294,967,295 is exceeded though! Can anyone tell me with certainty or hazard a guess what might happen here? I thank you very much for your time. The query that generates an auto_increment value larger than the largest value allowed for the column will fail with error 1062 (Duplicate entry 'xxx' for key 1) Matt ps - I'm doing this through PEAR::DB::mysql I am not exactly sure how PEAR::DB will propagate this error through its error handling interface. An easy way to test this is to create a temporary table that has a TINYINT as its auto_incrementing primary key, fill the table up and then watch to see what breaks. Cheers! --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?
D'oh - read too little, too fast. :) On Tue, Mar 25, 2003 at 05:55:42PM -0800, Zeev Suraski wrote: I believe he meant the query id's that the engine uses, and not the auto increment id's. Wez's response was accurate, we'll overflow at some point. This is basically because PHP was designed with short requests in mind. We could probably fix it relatively easily for ZE2. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proto void and return values...
On Tue, 2002-11-12 at 20:25, David Brown wrote: On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote: | Hi everyone: | | For functions prototyped as returning void, return values seem to be applied | at random. Some functions, such as trigger_error/user_error, srand, ob_start, | and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall | through, implicitly returning NULL to userland. Or perhaps I'v just thought about this entirely too long. Is it possible that the prototypes are just wrong in the documentation? Bingo! :) (or at least, that is my belief - I might be wrong :) --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PUT method support
On Tue, 2002-11-12 at 14:14, Hartmut Holzgraefe wrote: looks like this was a PHP3 only feature? http://www.php.net/manual/sv/printwn/features.file-upload.put-method.php Yes - this never made it out of PHP 3. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #20374 [NEW]: Performance enhancment forphp_mysql_do_connect. (fwd)
On Tue, 2002-11-12 at 00:47, Rasmus Lerdorf wrote: Seems like a good idea to me. Any volunteers? Zak? Working on it right now. :) Cheers! --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Embedded libmysql update
Hello All, Upgrading the embedded libmysql is taking me far too long. I have asked for the core MySQL devs to take care of it. A rather tired and frustrated, --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
On Mon, 2002-06-03 at 09:39, Sebastian Bergmann wrote: Jani Taskinen wrote: Currently, the bundled mysql is not been updated. (it's 3.23.39) Latest stable release is 3.23.49, AFAIK. I am told that Monty will see to it that Zak gets it updated before the next release :-) Yep. I started work on it again on the plane to Germany. I am using a script to handle the work so that it will be easier and faster in the future. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #16768: mysql_connect(localhost, ...) doesn't connect tolocalhost! (fwd)
On Wed, 2002-04-24 at 08:29, Derick Rethans wrote: Hey Zak, I think this is a nice thing for 4.2.1. I can reproduce it. I hope somebody can investigate this before friday (RC1 of 4.2.1 is scheduled then). Thanks for the heads up! I return from San Jose on the 25th - I will look at this on the 26th --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_tablename
On March 25, 2002 00:04, Manuzhai wrote: It might be nice to make an alias called mysql_table_name for this, then deprecate mysql_tablename, for the sake of consistency. What about that? Good point! Interestingly, mysql_tablename() is an alias for mysql_result(). However, your suggestion would make things more consistent - it will be added to the CVS version of PHP in a few minutes. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resume of my problem
On March 25, 2002 01:50, Alexandre Soares wrote:
HI,
I have a functino write in c, like as:
void addvalue ( int a, int b, int *c )
{
*c = a + b;
}
in php
?
phpinclude (alexlib);
addvalue ( 1, 2, c );
print ( Value c = $c );
?
what the procedure to make this ?
Dear Alexandre,
A better forum for your question is the php-general mailing list.
This list is for discussing the development *of* PHP.
--zak
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Better fix for PHP Safe Mode FilesystemCircumvention Problem
Hi Jason, Did this actually work? I wrote almost the same code on my own and tested it, only to find that nothing changed. I walked through the code, but did not spot a point where the CLIENT_LOCAL_FILES is actually used other than: % grep -rn CLIENT_LOCAL_FILES * ext/mysql/libmysql/libmysql.c:53:#define CLIENT_CAPABILITIES ... ext/mysql/libmysql/mysql_com.h:73:#define CLIENT_LOCAL_FILES128 ... I have not yet looked further than this. Monty cooked up a patch just before he went on vacation, but the patch is for a *way* newer version of libmysql and is not even remotely compatible. We (errr.. the PHP we that is) may wish to consider updating the embedded libmysql. --zak On Wed, 2002-02-27 at 09:59, Jason Greene wrote: This simple patch resolves this issue in a clean way, without introducing complex sql pre-processing code that introduces mutex problems. The only issue is that it requires a modification to libmysql.c, which provided that everyone here agrees with this fix, then I will post it to [EMAIL PROTECTED] to get there reaction. -Jason Index: ext/mysql/config.m4 === RCS file: /repository/php4/ext/mysql/config.m4,v retrieving revision 1.38 diff -u -r1.38 config.m4 --- ext/mysql/config.m4 30 Nov 2001 18:59:45 - 1.38 +++ ext/mysql/config.m4 27 Feb 2002 16:51:33 - @@ -41,6 +41,9 @@ if test $PHP_MYSQL != no; then AC_DEFINE(HAVE_MYSQL, 1, [Whether you have MySQL]) + if test $PHP_SAFE_MODE = yes; then + AC_DEFINE(DISALLOW_MYSQL_LOAD_LOCAL, 1, [Whether to disable load local]) + fi PHP_EXTENSION(mysql,$ext_shared) fi Index: ext/mysql/libmysql/libmysql.c === RCS file: /repository/php4/ext/mysql/libmysql/libmysql.c,v retrieving revision 1.9 diff -u -r1.9 libmysql.c --- ext/mysql/libmysql/libmysql.c 6 Nov 2001 16:59:07 - 1.9 +++ ext/mysql/libmysql/libmysql.c 27 Feb 2002 16:51:33 - @@ -50,7 +50,11 @@ uint mysql_port=0; my_stringmysql_unix_port=0; +#ifndef DISALLOW_MYSQL_LOAD_LOCAL #define CLIENT_CAPABILITIES (CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | CLIENT_LOCAL_FILES | CLIENT_TRANSACTIONS) +#else +#define CLIENT_CAPABILITIES (CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | CLIENT_TRANSACTIONS) +#endif #ifdef __WIN__ #define CONNECT_TIMEOUT 20 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com 403.244.7213 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Better fix for PHP Safe Mode FilesystemCircumvention Problem
On Thu, 2002-02-28 at 07:22, Andi Gutmans wrote: At 05:03 AM 2/28/2002 -0700, Zak Greant wrote: Hi Jason, Did this actually work? I wrote almost the same code on my own and tested it, only to find that nothing changed. I walked through the code, but did not spot a point where the CLIENT_LOCAL_FILES is actually used other than: % grep -rn CLIENT_LOCAL_FILES * ext/mysql/libmysql/libmysql.c:53:#define CLIENT_CAPABILITIES ... ext/mysql/libmysql/mysql_com.h:73:#define CLIENT_LOCAL_FILES128 ... I have not yet looked further than this. Monty cooked up a patch just before he went on vacation, but the patch is for a *way* newer version of libmysql and is not even remotely compatible. We (errr.. the PHP we that is) may wish to consider updating the embedded libmysql. You (as in MySQL AB) were supposed to keep it up-to-date. Tim used to do it but I think he has left. Please ask Monty about it :) Heh. Spank me Andi! ;) We will get it updated asap - maybe it can slip in for 4.2.0? :) -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com 403.244.7213 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem -tested
On Wed, 2002-02-27 at 05:40, [EMAIL PROTECTED] wrote: Hello, I think it's a bad idea to patch extension for flaws not in PHP itself. Furthermore, this adds a performance loss to every query. Did you do any benchmarks with it? Anyway... I still think it's a bad idea, and from what I've heard Zak is talking with MySQL about this. +1 This is not a PHP problem. We (the PHP we, that is :) can't go around patching PHP for every client lib that we support. That would be hell to deal with for the developers. We (the MySQL we, that is :) will have a patch shortly. Additionally, an upcoming release of MySQL will feature an additional permission to control this case. -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com 403.244.7213 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] PHP 4.2.0 release process
On Wed, 2002-02-27 at 11:31, Derick Rethans wrote: Hello folks, after some overenthausiastic actions of me today I'd like to do it the formal way now. I think it's a good idea to start working on a PHP 4.2.0 release now. Some interesting additions were added, the file upload code was rewriten and probably a lot more. I propose to branch to PHP_4_2_0 at next Wednesday March 6th. This should give most of you enough time to get your new code in. After that the QA team should gather the critical bugs and evaluate if they should be fixed before the 4.2.0 release. After this is evaluated it's time for the first RC, after which we can work at getting all those nasty little bugs out before we release. In a few minutes I'll write another mail to QA with things that should be tested a lot, I believe Zak has some notes about that too. Yup. Anyone want to volunteer to give me a hand on detailing all of the various issues - I am setting this upcoming weekend to work on it. -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com 403.244.7213 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: 4.2.0 CLI
On Wed, 2002-02-27 at 20:23, Yasuo Ohgaki wrote: Jim Winstead wrote: In php.dev Edin Kadribasic [EMAIL PROTECTED] wrote: 1. If you compile CGI binary and then issue 'make install' it will be installed in $PREFIX/bin, then CLI will be put in the same place overwriting it. Any suggestions on what to do in this situation? imho, the cgi binary should get called php.cgi. jim Sound nice to me. +1 Good idea! How about php-cgi instead so that some wacky sysadmin does not think that it is a cgi script and drop it into a cgi-bin directory? :) Also, is using the cli build of PHP going to break any old scripts? --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZE repositories
Zeev wrote: ... It should be noted that I believe it'll be better for the manual to lose the ugly license it's under and move to the openbook license, than the other way around. But I've already done my share of license wars in my life - if you want to talk to New Riders, go ahead. I will talk to Stephanie Wall at New Riders about this. -- For technical support contracts, goto https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15375 Updated: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 Assigned To: zak New Comment: Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com Previous Comments: [2002-02-05 06:22:51] [EMAIL PROTECTED] Humility is a dish best served lukewarm... I should have read more carefully. :) While Rasmus has spoken on this issue, but I will take a closer look at it tomorrow. [2002-02-05 06:08:01] [EMAIL PROTECTED] while that would be a obvious solution, this is an CLIENT-matter (the client sends the file) - and the File-privilege is only affecting the ability to load files that are stored on the server (and not in the client). The problem discussed is in the way that PHP will allow for any user to upload an arbitary file form the local server (where php runs) to the MySQL-server. IE: I set up a server running MySQL (or faking it, whatever) .. which just implements the receiver-part of the send_file_to_server-function in libmysql. This will allow me to transfer any file that the user PHP runs under on the server has access to, regardless of safe_mode, etc. The keyword 'local' is probably the cause of confusion, since this causes the file to be loaded from the client - and not the server (where the File-privilege has effect). [2002-02-05 01:32:49] [EMAIL PROTECTED] Thank you for your report! The BugTraq advisory is spurious. Issues of this nature can be avoided by revoking the FILE permission of the database user. Review: http://www.mysql.com/doc/M/y/MySQL_Database_Administration.html http://www.mysql.com/doc/P/r/Privilege_system.html [2002-02-04 21:33:31] [EMAIL PROTECTED] it occured to me (while brushing my teeth in fact :)) that this may be something that has to be patched in the query-parser instead, since the solution i'm talking about will break if the user decide to build from a custom libmysql-installation. [2002-02-04 21:10:42] [EMAIL PROTECTED] A message was posted at bugtraq earlier about a problem with safe_mode and the mysql-library used. the message is available here: http://www.orakel.ntnu.no/~matslin/php4_safe_mode.txt I searched the bugdb, but the bug doesnt not seem to be reported. As the author says in the mail, this may be a problem with other extensions as well. As far as i can see, this could probably be fixed in the send_file_to_server-function in libmysql.c, more specific somewhere around line 1776 (there is also some mention about this in the mail). The 'bug' makes it possible to read all files readable for php, even if its running in safe mode, basedir-restrictions etc. More info in the mail. -- Edit this bug report at http://bugs.php.net/?id=15375edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15375 Updated: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 Assigned To: zak New Comment: Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com Previous Comments: [2002-02-05 09:53:11] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 06:22:51] [EMAIL PROTECTED] Humility is a dish best served lukewarm... I should have read more carefully. :) While Rasmus has spoken on this issue, but I will take a closer look at it tomorrow. [2002-02-05 06:08:01] [EMAIL PROTECTED] while that would be a obvious solution, this is an CLIENT-matter (the client sends the file) - and the File-privilege is only affecting the ability to load files that are stored on the server (and not in the client). The problem discussed is in the way that PHP will allow for any user to upload an arbitary file form the local server (where php runs) to the MySQL-server. IE: I set up a server running MySQL (or faking it, whatever) .. which just implements the receiver-part of the send_file_to_server-function in libmysql. This will allow me to transfer any file that the user PHP runs under on the server has access to, regardless of safe_mode, etc. The keyword 'local' is probably the cause of confusion, since this causes the file to be loaded from the client - and not the server (where the File-privilege has effect). [2002-02-05 01:32:49] [EMAIL PROTECTED] Thank you for your report! The BugTraq advisory is spurious. Issues of this nature can be avoided by revoking the FILE permission of the database user. Review: http://www.mysql.com/doc/M/y/MySQL_Database_Administration.html http://www.mysql.com/doc/P/r/Privilege_system.html [2002-02-04 21:33:31] [EMAIL PROTECTED] it occured to me (while brushing my teeth in fact :)) that this may be something that has to be patched in the query-parser instead, since the solution i'm talking about will break if the user decide to build from a custom libmysql-installation. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15375 -- Edit this bug report at http://bugs.php.net/?id=15375edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zak@php.net address mail forward change
Hello All, Could someone with the needed karma please point my [EMAIL PROTECTED] address to my [EMAIL PROTECTED] address? Thanks! -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)
On Mon, 2002-02-04 at 22:23, James E. Flemer wrote: Comments on this? I am going to take a look at the code in the mysql extension, and at the code in mysql as well tomorrow. Not sure if this is directly a PHP problem (vs a mysql problem), but it is something that PHP *could* block it seems. IIAR, this is not really a weakness, merely a configuration issues. Wou can deny MySQL users access to the file based functions very easily. REVOKE FILE ON db TO user... Will do a bit more research to ensure that this is truly bogus. --zak -- For technical support contracts, goto https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15375 Updated: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 New Comment: Thank you for your report! The BugTraq advisory is spurious. Issues of this nature can be avoided by revoking the FILE permission of the database user. Review: http://www.mysql.com/doc/M/y/MySQL_Database_Administration.html http://www.mysql.com/doc/P/r/Privilege_system.html Previous Comments: [2002-02-04 21:33:31] [EMAIL PROTECTED] it occured to me (while brushing my teeth in fact :)) that this may be something that has to be patched in the query-parser instead, since the solution i'm talking about will break if the user decide to build from a custom libmysql-installation. [2002-02-04 21:10:42] [EMAIL PROTECTED] A message was posted at bugtraq earlier about a problem with safe_mode and the mysql-library used. the message is available here: http://www.orakel.ntnu.no/~matslin/php4_safe_mode.txt I searched the bugdb, but the bug doesnt not seem to be reported. As the author says in the mail, this may be a problem with other extensions as well. As far as i can see, this could probably be fixed in the send_file_to_server-function in libmysql.c, more specific somewhere around line 1776 (there is also some mention about this in the mail). The 'bug' makes it possible to read all files readable for php, even if its running in safe mode, basedir-restrictions etc. More info in the mail. -- Edit this bug report at http://bugs.php.net/?id=15375edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15336 Updated: New mysql function: mysql_real_connect
ID: 15336 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: any PHP Version: 4.1.1 New Comment: Hey Georg, I will be back to PHP stuff in a few days and will be working on the MySQL extension. There should be support for selecting the database on mysql_connect, and may be support for mysql_options. There is a proposal in the Dev list archives. I don't currently have a copy to send. Previous Comments: [2002-02-01 18:47:14] [EMAIL PROTECTED] Since version 3.22.x we have a mysql_real_connect instead of mysql_connect + mysql_db_select in the mysql C-API. If you come from C, its annoying, to use the (deprecated) functions mysql_connect + mysql_select_db. Its ok for BC, but mysql_real_connect should be art of the state. Georg Edit this bug report at http://bugs.php.net/?id=15336edit=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]
[PHP-DEV] Re: [Zend Engine 2] Heredoc-Syntax
On Wed, 2002-01-30 at 04:04, [EMAIL PROTECTED] wrote: On Wed, 30 Jan 2002, Yasuo Ohgaki wrote: therefore i wrote 'on its own line'. i suppose heredoc is handled by the scanner, so this should not be a problem. It's handled by the scanner indeed yohgaki: you were talking about reasons and mentioned only one that isn't a reason for me. any other reasons ? As I mentioned, feel free to write and submit patch :) PS: You are better to search archive, there were discussion regarding heredoc patch. It's not directly related to this change, but it may help. The last patch was rejected, IIRC. It's fairly easy to patch, the question is if we want it. Andi, what's your statement on this? I don't see why the heredoc label should be on the first column anyways. I talked to [EMAIL PROTECTED] about this quite some time ago. IIRC, we agreed that - heredoc syntax was an acceptable way to handle this. The - syntax would work like the same way as - in bash. Of course, I never got around to implementing it... :) -- For technical support contracts, goto https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Zak Greant [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB /_/ /_/\_, /___/\___\_\___/ Calgary, Canada ___/ www.mysql.com -- 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 #8314 Updated: Setting the error_log = syslog does not work on Win2k
ID: 8314 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PHP options/info functions Operating System: Win2k pro PHP Version: 4.0.3pl1 New Comment: I don't run Win2k (or any m$ product FTM) any more. Could someone else test this? Previous Comments: [2002-01-11 16:55:03] [EMAIL PROTECTED] Any news on this? [2001-01-08 13:01:03] [EMAIL PROTECTED] this is what I get from today's CVS: The description for Event ID ( 2000 ) in Source ( c-client ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: c-client[1368]; PHP Warning: Failed opening 'index.html' for inclusion (include_path='./') in [path] on line 4. [2000-12-18 12:57:25] [EMAIL PROTECTED] Setting the error_log directive to syslog does not work as anticipated under Win2k. Logged errors generate this entry in the Application Log: The description for Event ID ( 2000 ) in Source ( c-client ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: c-client[2052], foo. Edit this bug report at http://bugs.php.net/?id=8314edit=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] Re: migrating PHPs across machines...
On 2002-12-01 05:24, Manuel Lemos wrote: Hello, [EMAIL PROTECTED] wrote: [insert other shameless plugs here] What is the matter with you? Why this hostility again? Does the truth bothers you? Are you going to start yet another repress Manuel because we don't want him to help PHP users thread? Get a grip! I wish new guys like you that just got @php.net stop acting as if you it got over your head and you think you are a big shot because of that and you the right to act this arrogant. What? You did not like my response? That's to make you think again next time before you decide to get me started with your repressing arrogance. :-( Chill Manuel! If your responses to the smallest slight were less overblown/entertaining, people would taunt you *much* less often. Also, user level questions should stay on the general or db list. --zak -- 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: migrating PHPs across machines...
On 2002-12-01 05:41, Manuel Lemos wrote: Zak Greant wrote: On 2002-12-01 05:24, Manuel Lemos wrote: Hello, [EMAIL PROTECTED] wrote: [insert other shameless plugs here] What is the matter with you? Why this hostility again? Does the truth bothers you? Are you going to start yet another repress Manuel because we don't want him to help PHP users thread? Get a grip! I wish new guys like you that just got @php.net stop acting as if you it got over your head and you think you are a big shot because of that and you the right to act this arrogant. What? You did not like my response? That's to make you think again next time before you decide to get me started with your repressing arrogance. :-( Chill Manuel! If your responses to the smallest slight were less overblown/entertaining, people would taunt you *much* less often. I don't think there is an excuse for Derick sistematic arrogance. Still, that is just my opinion. I feel that you have read too much into too little. However, this is only my opinion as well. :) I wish the Dericks of this this list would better spend their time helping that Zaks instead of just annoying the Manuels because they hardcoded in their minds that repressing the Manuels is a much better thing to do! :-) But Derick *does* spend time helping me.* :) I still think that with just a teeny bit of restraint on both sides, this would not happen. Also, user level questions should stay on the general or db list. Yes, sorry, my mistake, I didn't quite notice the list this was going to, I just followed-up the original post. :) No worries - I have done the same many times. * As have *many* people on this list - even you. :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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: migrating PHPs across machines...
On 2002-12-01 09:23, Manuel Lemos wrote: [cut] His follow messages just confirm what I said. I find intolerance in both sides of the argument. But Derick *does* spend time helping me.* :) I still think that with just a teeny bit of restraint on both sides, this would not happen. I was kidding, but since you took it seriously, just by going to http://bugs.php.net/search.php I can see that there 920 outstand bug reports to be addressed. How come anybody can think that repressing Manuel is a better way to spend time than fixing all those bugs? I looks like Derick wants to show off and exhibit his official @php.net badge and act like a PHP mailing lists watchdog. Never mind, lets let him figure that he'd better have a life of his own instead of bothering to step on others' feet. Manuel, Derick spends a fabulous amount of time on improving PHP. I very much respect his effort and generally quiet, determined demeanor. He is not showing off his status. He is venting frustration that many in the community feel. Many of the long and loud threads on this list over the last little while have been pointless fights... You defend yourself so vigorously and take offense so quickly that people have trouble relating to you. [cut] It was not intended, but now you have to face the justice or Mr. Net cop Derick. Actually I don't - in fact, I don't recall ever having been troubled by those who disagree with you. I am probably the least adept of the people actively involved with the development effort and I make a lot of mistakes and foolish suggestions, yet no one troubles me... Just to relax, you know that 4 years ago I wrote a book named something that would be translated as Being on the Internet. I have one chapter that talks about typical behaviours that the Internet make outstand in users. One of the described behaviours is what I called the Net Cop. It is that guy that thinks of himself of a big shot that knows all and is going to fix the world by repressing others. Derick just reminded me of a Net Cop. Anyway, I tend to understand people like him, because as I explained in the book, usually people just repress others because they are or at least were repressed by others in the past. Despite they hated it, they just do the same and repress others with shouting at them with public messages to try to humilliate them, just like Derick tried. Never mind, nothing that some good analysis sessions would not solve! :-) Manuel, you are very intelligent and have the benefit of being older than many of us on the list - why can't you identify your own behavior in the bad things that you attribute to others? I believe that you are a net cop. Derick certainly is not - I somewhat am -- just by the virtue of not being able to leave other people's discussions well enough alone. :) Anyone remember when I was *stupid* enough to try and moderate the last big fight between Zeev and Sascha? Anyway, talking about books, and to not completely waste this thread I have just skimmed your book, PHP Functions Essential Reference. I must congratulate you and your co-authors for the book. It is a very good approach to make turn a reference manual into a much more useful PHP programming hand book. Thank you! We worked hard on providing cookbook-style examples to match the reference material. I am sorry I could not yet find time to publish a review in the PHP Classes site because I have been very busy with things that gave me a lot of work like completely removing the uses of strtok function from the site code because PHP developers broke it after version 4.0.6 and I could not avoid the upgrade to use the APC cache to speedup the site service. This is an example of the negative behavior that we discuseed. Everyone know that you have issues with this. Each time that you bring it up without adding any constructive input with it, it makes people angry. If I found what I considered to be a flaw in Metabase, and continually hounded you on the problem without offering any compromise or assistance, you would likely not find me very good company. I probably only have time to review your book in February because I am still very busy with a new release of Metabase to be out on its second anniversary since its first public release that will happen on the 18th. There are a few inovating features that I want release but I have to work a lot to make it happen in time. Then I need to get back to MetaL developement that will also have its first public release soon, hopefully some time next month. But don't worry I will make a nice review of your book anytime until then. No worries on timing. Regards, Manuel Lemos Regards, Manuel Lemos -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e
Re: [PHP-DEV] Re: migrating PHPs across machines...
On 2002-12-01 05:14, Abhimanyu_Bhola wrote: Thanks a lot. # but I dont think I need to do this if I dont switch my DB server !!! and, # what to do regarding the php.ini file? Do I have to manually transfer all the settings by examining the old and new ones or how to go about it? Hi Abi, While Manuel was kind enough to answer you, this question is best suited to the PHP database or general mailing list. The Dev list is (usually) for discussing issues related to building PHP instead of building with PHP. --zak -- 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] Taking a short break.
Hey All, I need to take a couple of weeks off to avert financial distaster/get some contracts finished up/get ready for a new job. See you next month. :) (Note: If there is anything that needs my attention, feel free to mail me directly! I will be around... :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] E_NOTICE
On 2002-10-01 07:38, Derick Rethans wrote: Hello, can somebody clarify why a E_NOTICE prints 'Warning' and E_USER_NOTICE prints 'Notice'. IMO it is more clear to print 'Notice' in both cases. It probably has something to do with maintaining backwards compatibility. Could we set a php.ini flag to control this behavior? ; /me grins, dodges, runs and hides... --zak -- 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] E_NOTICE
On 2002-10-01 07:49, [EMAIL PROTECTED] wrote: On Thu, 10 Jan 2002, Zak Greant wrote: On 2002-10-01 07:38, Derick Rethans wrote: Hello, can somebody clarify why a E_NOTICE prints 'Warning' and E_USER_NOTICE prints 'Notice'. IMO it is more clear to print 'Notice' in both cases. It probably has something to do with maintaining backwards compatibility. Could we set a php.ini flag to control this behavior? ; :) Anyway, it doesn't make sense to me. IMO it should just show 'Notice' for both cases. Agreed. Having anything else is just confusing. --zak -- 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: Behaviour of $array1 + $array2
On 2002-10-01 17:33, Yasuo Ohgaki wrote:
Markus Fischer wrote:
Can someone point me where the following behaviour is documented:
$ php -q
?
$foo = array(27 = 'Ene');
$bar = array(-1 = 'Mene');
$baz = $foo + $bar;
var_dump($baz);
?
array(2) {
[27]=
string(3) Ene
[-1]=
string(4) Mene
}
cheers
- Markus
I guess it's not.
There is note explains this behavior. Accoding to the note,
PHP Developer's Cookbook claims (p. 87 and sort of on p. 108)
that '+' is syntactic sugar for array_merge.
Also, there have been discussions on Dev about this issue before.
Might be a bit tough to find though. :)
--
Zak Greant
PHP Quality Assurance Team
http://qa.php.net/
We must be the change we wish to see. - M. K. Ghandi
--
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: Behaviour of $array1 + $array2
On 2002-10-01 21:28, Markus Fischer wrote: On Thu, Jan 10, 2002 at 05:58:28PM -0700, Zak Greant wrote : [cut] Also, there have been discussions on Dev about this issue before. Might be a bit tough to find though. :) Hmm .. well, at least, it should be clearly documented. I agree! I just wanted to make sure that you knew that this had been covered once before -- there might be some useful information in the archives. --zak -- 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 #14935 Updated: spaces NOT escaped by A..z
ID: 14935
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Documentation problem
PHP Version: 4.1.1
New Comment:
We should probably take a closer look at this problem. I
verified that addcslashes had the currently documented
behaviour a while ago. If it has changed, we have a
problem.
Previous Comments:
[2002-01-09 21:09:38] [EMAIL PROTECTED]
Confirmed, will fix in CVS.
Status - Closed
[2002-01-08 15:24:48] [EMAIL PROTECTED]
http://www.php.net/manual/en/function.addcslashes.php
says `and space characters' but this is not true; on my
system
addcslashes('foo[ ]','A..z')
results in
\f\o\o\[ \]
not
\f\o\o\[\ \]
Edit this bug report at http://bugs.php.net/?id=14935edit=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 #14938 Updated: No htmlescape() function for PHP4
On 2002-8-01 17:36, [EMAIL PROTECTED] wrote: ID: 14938 Updated by: philip Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Duplicate Bug Type: Documentation problem Operating System: Linux PHP Version: 4.1.1 Assigned To: imajes New Comment: Be sure to discuss this with Zak, see bug #14418 which stemmed from this htmlescape() doc bug, not sure where he's at on it. I'm sure he wouldn't mind if you did a commit though :) I need to get off my lazy ass and fix it. :) -- 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 #14943 Updated: security issue with apache's ScriptAlias and php.exe
ID: 14943 Updated by: zak Old Summary: security issue with apache's ScriptAlias and php.exe Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Apache related Operating System: 98 PHP Version: 4.1.1 New Comment: Thank your for your report! However, please review the bug database for bug reports before submitting new ones. Previous Comments: [2002-01-09 01:22:54] [EMAIL PROTECTED] Apache 1.3.22 PHP 4.1.1 ...the latest versions at the moment. in the httpd.conf of apache, i have: AddType application/x-httpd-php .php ScriptAlias /php/ c:/mirc/apache/php/ Action application/x-httpd-php /php/php.exe typing this into my browser: http://127.0.0.1/php/php.exe?C:\mirc\apache\apache\logs\access.log allowed me to view the file. i noticed the extra traffic heading out from my computer and checked the access.log myself and found someone using php.exe and the scriptalias like this. Edit this bug report at http://bugs.php.net/?id=14943edit=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]
[PHP-DEV] Bug #14890 Updated: is_uploaded_file does not work correctly
ID: 14890 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Feature/Change Request Operating System: Unix/Linux PHP Version: 4.1.1 Previous Comments: [2002-01-06 09:57:40] [EMAIL PROTECTED] This function can return a false positive if you set a MAX_FILE_SIZE limit in the HTML form sending the file and then proceeed to send a file bigger than this max. If a call is made to _is_uploaded_file to see if the file made it to the server, the function will return TRUE even though the file doesn't exist on the server and the filename is set to none. In this case, the function _is_uploaded_file should return FALSE, not TRUE because it has not been uploaded. Edit this bug report at http://bugs.php.net/?id=14890edit=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]
[PHP-DEV] Bug #14714 Updated: String tokenizer appears to only work with tokens of size equal to one.
ID: 14714
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Old Bug Type: Strings related
Bug Type: Documentation problem
Operating System: linux redhat 7.0
PHP Version: 4.1.0
New Comment:
strtok splits a string into tokens, each token delimited
by any character from the token string.
Changing to documentation problem. Will fix shortly.
Previous Comments:
[2002-01-04 19:03:34] [EMAIL PROTECTED]
Please create a php file with the following content, the version number
of PHP will appear in the output:
?php
phpinfo();
?
Let us know what version you are on.
Sean
[2001-12-27 02:35:26] [EMAIL PROTECTED]
This code does not appear to work (it is almost a cut and paste from the
manual with the token changed). From experimentation I think it is
beacause the token is two characters long. I am not sure if this is a
bug or a undocumented property of this function.
$string = This is an example string;
$tok = strtok($string,%s);
while ($tok) {
echo Word=$tokbr;
$tok = strtok(%s);
}
I am sorry I can't be sure of the version of PHP on this server. I only
have ftp access.
Thanks for such a great product!
Edit this bug report at http://bugs.php.net/?id=14714edit=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]
[PHP-DEV] Proposed updates and extensions to the MySQL extension
Hello All,
Monty has a series of proposed changes and updates to the MySQL extension
(along with a few ideas of mine that we have discussed) that I would like to
present to the dev list for feedback and review.
Synopsis of Proposed Changes
Update the PHP built-in MySQL library to support MySQL 4.0.1
Extend mysql_connect()/mysql_pconnect() to allow the optional selection
of a default database, a MySQL config file and a group within the selected
config file.
The default database parameter will allow the default database to be
selected at connection time, instead of requiring a separate call.
The other parameters will allow the connection to use the client connect
options set in the config file (such as passwords, connection timeouts,
etc.) This will allow passwords to be stored outside of the PHP script.
Allow persistent connections to be closed and 'pruned'. Possible ways to
implement this include adding mysql_pclose(), which would close a
persistent connection and remove it from the connection cache.
...or add a function that flags persistent connections as removeable. Calls
to mysql_close() made on a flagged connection would close it and remove it
from the connection cache. i.e. mysql_trim_pconnections (); An optional
argument could allow the connections to be pruned down to a certain number.
Create an OO-based wrapper for the MySQL extension. The wrapper would
provide the user with access to all of a database's information without
requiring explicit queries or functions calls to retrieve the data. The
user would not need to call call mysql_db_name, mysql_field_*,
mysql_list_fields, etc. The wrapper would also encompass the rest of the
MySQL extension's functionality.
The major benefits of the wrapper would be:
- Small and simple API. The number of functions would drop from 41 to
around 12.
- Full information on the server, databases, tables and fields could
easily be viewed with one call to var_dump()
- Connection handles, etc. would all be managed by the object
- Error messages, last insert id, etc. would be stored as object
properties.
The library would work something like the following:
// Connect to MySQL and select database
$mysql = new oo_mysql ('localhost', 'user', 'password', 'db');
// Accessing the tables property triggers a SHOW TABLES query
var_dump ($mysql-tables);
Notes: The wrapper would not retrieve the information until the
corresponding property was requested. This will keep the size of the object
down.
As always, feedback is welcome! :)
Thanks!
--zak
--
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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 02:01, Markus Fischer wrote: On Thu, Jan 03, 2002 at 01:19:03AM -0700, Zak Greant wrote : The major benefits of the wrapper would be: - Small and simple API. The number of functions would drop from 41 to around 12. But you know you just can't remove the existing functions. Of course not!! :) The OO wrapper would not replace the current extension. --zak -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 02:43, Alexander Merz wrote: Create an OO-based wrapper for the MySQL extension. The wrapper would provide the user with access to all of a database's information without Yeah, lets re-invent PEAR:DB :) Such things are already on the ToDo list for PEAR::DB. What makes you think that this could not be a part of PEAR::DB? ;) --zak -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 03:39, Lukas Smith wrote: Well PHP and MySQL are a very popular combo .. but I do not see a point in separating the API's even further ... DB API's are a major concern for myself right now too It would be really nice to work more in the direction of unifying all of the API's on a C level Other than that there is nothing against doing that change .. but I think it would only make sense to do it across the board I plan to keep my focus on this very small to avoid distraction. :) I am currently working on a PHP based implementation that uses Andrei's overload extension. Once I this is somewhat stable and users have had a chance to work with it, I plan to implement it in C. --zak -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 07:32, Joao Prado Maia wrote: [cut] My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. I really don't feel very good with yet another database abstraction package, and this time just for MySQL. I say database abstraction not in the sense that it will abstract everything, but that it gives a thin layer of abstraction to the underlying database. In any case, I _really_ hope you will talk with Stig and get to know more about the latest discussions (flame-wars?) in PEAR-DEV about the upcoming re-write of PEAR::DB and also about the intention of re-writing it in C once it is stable. Hi Joao, Thanks for the feedback! I understand your objections, but do not agree with all of them. I am not competing with the PEAR project. I am talking about proposed functionality and have avoided discussions of whether it should be a part of PHP, PEAR/PECL or neither. There is significant work to be done before this would be integrated with anything. No one will be forced to use the wrapper. I am currently focusing on MySQL rather than on all databases. Developing this for a single database reduces the design overhead. The average new user will not need to learn multiple APIs. Initially, they will choose an API that works for them and then learn the bare minimum needed to use it. I am glad that others are discussing similar ideas and would be happy to discuss or collaborate. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 07:06, Phil Driscoll wrote: Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. I know that you don't like OO Phil. :) I also dislike (most) OO for many applications. I believe that during this stage, OO is the easiest way to rough this idea out. I will be more than happy to look at a proceedural interface later on. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 11:29, Andi Gutmans wrote: Zak, You will probably be better off waiting for the ZE2's new object overloading facilities. It will hopefully be easier to write and will allow you to do some things which you can't do today. If you write it for ZE1 your extension's API might look different than if you had written it for ZE2 due to some existing limitations, changing it later on for ZE2 would then cause a BC problem. Hi Andi, Thanks for the warning! I am partially doing this for practice/fun - as long as we keep the extension away from PEAR/PHP it can be updated to ZE2 when the time comes without breaking BC. :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 06:44, [EMAIL PROTECTED] wrote: ** Reply to note from Markus Fischer [EMAIL PROTECTED] Thu, 3 Jan 2002 15:18:16 +0100 On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] Proposed updates and extensions to the MySQL extension
On 2002-3-01 15:43, Joao Prado Maia wrote: So ? I didn't see any C code from Zak either. If all we are doing right now is speculating on the creation of a PHP based 'prototype' of this MySQL-only abstraction thing, why is it more interesting than a existing package like PEAR::DB ? Talk is just that - talk. The weird part is that Zak probably know about PEAR::DB and he might even know about Stig's plan on writing a C port of a stable version of it. Maybe I'm wrong, but I just don't feel very good about all this duplication of efforts and even more about a abstraction class _just_ for MySQL. I do know about PEAR::DB - I looked at the IDEAS file to see what was planned. I probably should have reviewed the PEAR DEV list, but - hey - I can't read every PHP list. I respect the work that the PEAR team has done. Please don't make an issue of something that we do not need to worry about yet. I will keep writing my code. When I have something useable, I will present it to whoever is interested. It can be integrated into PEAR or PHP or nothing -- whatever works best for the users. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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 #13368 Updated: 2nd call to @mssql_query does not fill $php_errormsg s'd be'permission denied'
ID: 13368
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: MSSQL related
Operating System: SuSe Linux 7.1
PHP Version: 4.0.6
New Comment:
This may have just been corrected in the development
version of PHP.
Could you please download and build the php4-latest
snapshot from http://snaps.php.net?
Alternately, the change should be in the next release of
PHP.
Previous Comments:
[2001-09-18 10:30:19] [EMAIL PROTECTED]
I'm using MSSQL 7.0 on WinNT4.0, FreeTDS 0.51 with tdsver=4.2, client is
SuSe Linux 7.1, Apache 1.3.19, PHP 4.0.6.
I've run into troubles while checking SELECT permissions for several
tables within a single db connection. In a typical case, I think, this
should work fine:
##
$php_errormsg = '';
@mssql_query(SELECT * FROM $table);
if (!empty($php_errormsg)) {
echo It seems you cannot access table $table;
}
##
But this code works only the first time within a single connection to
MSSQL server. The 2nd call to such a code does nothing with the contents
of $php_errormsg, even when there should be message 'Permission denied'.
(Sometimes the next call to mssql_query without '@' fires the exception.)
I've also tried a piece of code like this, but the result was the same:
##
$php_errormsg = '';
$result = mssql_query(SELECT * FROM $table);
if (! $result) {
echo It seems you cannot access table $table;
}
##
It seems to me, that there is a bug somewhere. The only way to handle this situation
seems to be reconnecting to the MSSQL server. Any help?
Edit this bug report at http://bugs.php.net/?id=13368edit=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 #14782 Updated: key_exists renamed to array_key_exists
Well said. :) Well enough that the developer who made the change has asked to have an alias added. Attached is the required patch. The alias should appear in the next maintenence release of PHP. --zak On 2002-2-01 09:10, [EMAIL PROTECTED] wrote: ID: 14782 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Old Assigned To: zak Assigned To: New Comment: I understand the issue or having functions disappear and then reappear.. [cut] Index: ext/standard/basic_functions.c === RCS file: /repository/php4/ext/standard/basic_functions.c,v retrieving revision 1.433 retrieving revision 1.434 diff -u -r1.433 -r1.434 --- ext/standard/basic_functions.c 30 Dec 2001 09:36:24 - 1.433 +++ ext/standard/basic_functions.c 2 Jan 2002 21:21:48 - 1.434 @@ -17,7 +17,7 @@ +--+ */ -/* $Id: basic_functions.c,v 1.433 2001/12/30 09:36:24 zak Exp $ */ +/* $Id: basic_functions.c,v 1.434 2002/01/02 21:21:48 zak Exp $ */ #include php.h #include php_main.h @@ -789,6 +789,7 @@ /* aliases from array.c */ PHP_FALIAS(pos, current, first_arg_force_ref) PHP_FALIAS(sizeof, count, NULL) + PHP_FALIAS(key_exists, array_key_exists, NULL) /* functions from assert.c */ PHP_FE(assert, NULL) -- 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] Moving extensions to PECL
On 2001-31-12 11:38, Jon Parise wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? We should probably add cybermut to the list as well. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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 #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 New Comment: Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. Previous Comments: [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=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]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Old Assigned To: Assigned To: zak New Comment: Assigning to myself Previous Comments: [2001-12-31 16:21:14] [EMAIL PROTECTED] Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=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]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Assigned To: zak New Comment: As Someone Who Shall Not Be Named Because They Are Also On Vacation has pointed out to me off list, it would be a bad thing to have functions disappearing and reappearing between versions. The function shall stay as is - please adjust your scripts accordingly. Thank you. Previous Comments: [2001-12-31 16:37:26] [EMAIL PROTECTED] Assigning to myself [2001-12-31 16:21:14] [EMAIL PROTECTED] Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=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]
[PHP-DEV] Bug #11993 Updated: mysql_close closes incorrect db handler
ID: 11993 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: I will take a look at this. Previous Comments: [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati [2001-12-13 06:26:24] [EMAIL PROTECTED] No feedback. Closing. [2001-11-20 19:55:37] [EMAIL PROTECTED] Can you try if the problem still persists with latest RC http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-10-24 00:59:24] [EMAIL PROTECTED] missing status [2001-07-11 13:58:35] [EMAIL PROTECTED] hi zak, thanks for your answer. in my opinion, php must have some matrix, where you stores the number of connect and close calls with the connection id. this will probably solve the problem. ps: i use these multiple connections in oop environment, where a global connection id, is not the best idea. or? ati The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11993 Edit this bug report at http://bugs.php.net/?id=11993edit=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]
[PHP-DEV] Bug #13456 Updated: mysql_query() returns incorrect result whith do not perform real MySQL state
ID: 13456 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: MySQL related Operating System: Linix PHP Version: 4.0.6 Old Assigned To: Zeev Assigned To: New Comment: Zeev fixed this. The fix should appear in the release that follows PHP 4.1.1 Previous Comments: [2001-11-20 18:52:15] [EMAIL PROTECTED] Being unkind, I assign this to Zeev ... :-) [2001-09-26 13:13:33] [EMAIL PROTECTED] We use MySQL 3.22.32 and recive false using mysql_query() wherever SQL is correct and has effect on database. So, in file ext/mysql/php_mysql.c line 99 must be at least such line: #if MYSQL_VERSION_ID 32233 instead of #if MYSQL_VERSION_ID 32224 Edit this bug report at http://bugs.php.net/?id=13456edit=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]
[PHP-DEV] Bug #13589 Updated: Persistent connections stay open and accumulate
ID: 13589 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: RedHat 7.1 PHP Version: 4.0.6 Old Assigned To: Assigned To: zak New Comment: Assigning to myself Previous Comments: [2001-11-20 12:55:15] [EMAIL PROTECTED] However, this is something else. This need to be investigated first. [2001-11-20 12:31:00] [EMAIL PROTECTED] This is what Derick said about this (in #14149): This is not a bug, the MySQL extension will open a new connection if the _current apache child_ has no open connection to MySQL. With this in mind, it's very normal to see that apache has multiple connections open to MySQL. [2001-10-07 17:33:26] [EMAIL PROTECTED] While trying to use persistent connections for performance on an ad server, connections to the MySQL server stay open and accumulate over time until it hits the max_connections setting is hit. Once this happens, MySQL refuses to allow connections. After looking at the MySQL process list, it seams that connections are not always recycled. In theory, idle established connections' Commands should be Sleep but curiously, it looks like connections not being recycled have Query command and a state of NULL. Presently using MySQL 3.23.36. Edit this bug report at http://bugs.php.net/?id=13589edit=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]
[PHP-DEV] Bug #14419 Updated: Please use Character-enable mysql_escape
ID: 14419
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: MySQL related
Operating System: All
PHP Version: 4.1.0
Old Assigned To:
Assigned To: zak
New Comment:
Thanks for the suggestion!
I will investigate this.
Previous Comments:
[2001-12-11 03:41:15] [EMAIL PROTECTED]
in file php-4.1.0/ext/mysql/php_mysql.c line 1365
---
Z_STRLEN_P(return_value) = mysql_escape_string(Z_STRVAL_P(return_value),
Z_STRVAL_PP(str), Z_STRLEN_PP(str));
---
could you change from
mysq_escape_string into mysql_
to something like
#if MYSQL_VERSION_ID 32321
len = mysql_escape_string(out, in, size);
#else
if (self) {
check_connection(self);
len = mysql_real_escape_string((self-connection), out, in, size);
}
else
len = mysql_escape_string(out, in, size);
#endif
(quote from mysql python module)
Edit this bug report at http://bugs.php.net/?id=14419edit=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]
[PHP-DEV] Bug #14498 Updated: undefined symbol: my_message_no_curses
ID: 14498 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: Cobalt Linux 5.0 PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: By not specifying a path to the MySQL libraries, you are using PHP's built-in library. I would guess this is a problem with MySQL - I will check it out. Previous Comments: [2001-12-13 17:36:06] [EMAIL PROTECTED] Compiled MySQL 3.23.46 with these configure options: ./configure \ --prefix=/usr/local/mysql \ --enable-assembler \ --with-low-memory Compiled PHP 4.10 with these options: ./configure --with-apxs=/usr/sbin/apxs \ --with-mysql=/usr/local/mysql \ --with-imap=/usr/local/src/imap-2000c \ --with-imap-ssl \ --with-zlib \ --enable-track-vars \ --with-gettext \ --with-gd \ --with-jpeg-dir=/usr/local/lib \ --with-mm=/usr/local/lib/mm \ --enable-sysvshm \ --enable-ftp Starting Apache 1.3.22 with apachectl start gives me this: Syntax error on line 238 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/local/mysql/lib/mysql/libmysqlclient.so.10: undefined symbol: my_message_no_curses I can work-around this bug by NOT specifying the dir when configuring PHP i.e. (--with-mysql as opposed to --with-mysql=/usr/local/mysql) Edit this bug report at http://bugs.php.net/?id=14498edit=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]
[PHP-DEV] Bug #11652 Updated: mysql_data_seek() and mysql_unbuffered_query() warning text
ID: 11652 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: All PHP Version: 4.0.6 Assigned To: zak New Comment: doh. Previous Comments: [2001-06-25 05:01:21] [EMAIL PROTECTED] When using mysql_data_seek() in conjunction with mysql_unbuffered_query() which obviously is not possible, I get a Warning: Offset 5 is invalid for MySQL result index [...] whilst the warning perhaps should have said that mysql_data_seek() aand mysql_unbuffered_query() cannot be used together. This might also be a documentation problem Edit this bug report at http://bugs.php.net/?id=11652edit=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]
[PHP-DEV] Bug #11993 Updated: mysql_close closes incorrect db handler
ID: 11993 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Assigned To: zak New Comment: doh. Previous Comments: [2001-12-31 18:56:34] [EMAIL PROTECTED] I will take a look at this. [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati [2001-12-13 06:26:24] [EMAIL PROTECTED] No feedback. Closing. [2001-11-20 19:55:37] [EMAIL PROTECTED] Can you try if the problem still persists with latest RC http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-10-24 00:59:24] [EMAIL PROTECTED] missing status The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11993 Edit this bug report at http://bugs.php.net/?id=11993edit=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]
[PHP-DEV] Bug #13589 Updated: Persistent connections stay open and accumulate
ID: 13589 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: RedHat 7.1 PHP Version: 4.0.6 Assigned To: zak New Comment: doh. Previous Comments: [2001-12-31 19:08:34] [EMAIL PROTECTED] Assigning to myself [2001-11-20 12:55:15] [EMAIL PROTECTED] However, this is something else. This need to be investigated first. [2001-11-20 12:31:00] [EMAIL PROTECTED] This is what Derick said about this (in #14149): This is not a bug, the MySQL extension will open a new connection if the _current apache child_ has no open connection to MySQL. With this in mind, it's very normal to see that apache has multiple connections open to MySQL. [2001-10-07 17:33:26] [EMAIL PROTECTED] While trying to use persistent connections for performance on an ad server, connections to the MySQL server stay open and accumulate over time until it hits the max_connections setting is hit. Once this happens, MySQL refuses to allow connections. After looking at the MySQL process list, it seams that connections are not always recycled. In theory, idle established connections' Commands should be Sleep but curiously, it looks like connections not being recycled have Query command and a state of NULL. Presently using MySQL 3.23.36. Edit this bug report at http://bugs.php.net/?id=13589edit=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]
[PHP-DEV] Bug #13933 Updated: error_log and HTTP redirect using header conflict
ID: 13933 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Output Control Operating System: Windows NT4 SP6 PHP Version: 4.0.6 Old Assigned To: zak Assigned To: yasuo New Comment: Assigning this to Yasuo :) Previous Comments: [2001-12-12 04:51:21] [EMAIL PROTECTED] Zak, is this bug analyzed? I'm trying to sort out output buffering problems. Thanks. [2001-12-10 20:40:37] [EMAIL PROTECTED] Assigning it to myself so that I don't forget about it. :) [2001-12-05 04:24:00] [EMAIL PROTECTED] I finally found time to test. Here it goes. First of all, PHP config is: error_log is not set display_errors is off log_errors is on error_reporting is standard (E_ALL ~E_NOTICE) Then, the page I'm testing: ? error_log (this is a test, 0); header(Location: index.php); ? And finally, the results: - in Apache's log file, I get these two lines: [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] this is a test [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] PHP Warning: Cannot add header information - headers already sent in d:\wwwroot\htdocs\csf_recette\titi.php on line 3 - the source of the generated page displayed in IE is as follow, eventhough nothing has been output: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1/HEAD BODY/BODY/HTML Conclusion: - error_log works fine, it does what I expect, but it might do a little more; - PHP complains about something being output *before* the call to header. I've tried removing this call (to header), my message is logged, and I *still* get the same output; - thus, somehow, the call to error_log produces PHP or Apache to generate this unexpected HTML code while logging; I've tried almost the same settings on another server (difference in php.ini is display_errors on) and it works quite fine. Could there be other parts of PHP's configuration, or even Apache's conf, altering the expected behaviour ? [2001-11-12 19:54:19] [EMAIL PROTECTED] Status - feedback (Zak! try to remember? :) [2001-11-12 17:01:23] [EMAIL PROTECTED] Sounds like error_log() was generating an error message because the error_log directive was not set. Once the error message was generated, output would be sent to the browser, causing the headers to be sent and the header() call to fail. Try unsetting the error_log directive in php.ini and run a script that only calls error_log(). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13933 Edit this bug report at http://bugs.php.net/?id=13933edit=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]
[PHP-DEV] Bug #14295 Updated: Scope of globals has changed
ID: 14295 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Variables related Operating System: Win2k PHP Version: 4.0.6 Assigned To: zak New Comment: I should really get around to examining this. :) Previous Comments: [2001-12-06 08:51:28] [EMAIL PROTECTED] I'm unable to reach you at [EMAIL PROTECTED]! Where should I send the password to? [2001-12-06 08:46:19] [EMAIL PROTECTED] Forgot to say this: Please let me know if you find the problem ; ) [2001-12-06 08:40:49] [EMAIL PROTECTED] zak: I have set up a webserver and ftp for you to do the tests you need. The account is running on the system which produces the problem. Feel free to use it as you like. NOTE: The server might be offline for a short while sometimes. This is because of redialing and submitting a new IP to DynDNS.org every 24 hours. Additionally the server will be down on Sunday, 12/9/01 00:00:00 Am to 10:00:00 Am european time. If you should have additional questions or wishes related to the account do not hesitate to ask me. HTTP and FTP: phpnet.homeip.net The password for the FTP will reach you by email. [2001-12-06 07:41:47] [EMAIL PROTECTED] Thanks for trying the scripts! If we are lucky, this bug report will help us find what weird thing makes $PHP_SELF behave strangely under Win32. Could you please try the same test with a different global value? [2001-12-05 01:49:07] [EMAIL PROTECTED] Zak: I did try it and could reproduce with your code. I found out, that it only happens when i'm running my scripts on Win2k. On Linux my scripts are running as expected and I don't need to declare $PHP_SELF global again. The only difference in my PHP configuration is: On Win2k virtual dirs is enabled, on Linux it's disabled. Well, I don't know where to set virtual directory support on/off, so I can't verify. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=14295 Edit this bug report at http://bugs.php.net/?id=14295edit=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]
[PHP-DEV] Bug #14295 Updated: Scope of globals has changed
ID: 14295
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Bogus
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
Old Assigned To: zak
Assigned To:
New Comment:
Hi Volker,
Thanks for setting up the web server for me. It made
testing a lot faster.
Thankfully, I could not reproduce the problem on your web
server. Flagging bug as bogus.
For proof of bogosity, see :
http://phpnet.homeip.net/v1.php
http://phpnet.homeip.net/v2.php
http://phpnet.homeip.net/v1.phps
http://phpnet.homeip.net/v2.phps
Also, here is a diff out the output of calling v2.php
directly and calling it via an include call in v1.php
None of the globals are missing in either case.
Additionally, the two are almost the same -- except for
the differences noted below.
--- v1.php Mon Dec 31 17:35:12 2001
+++ v2.php Mon Dec 31 17:35:02 2001
@@ -1,5 +1,5 @@
pre
-PHP_SELF: /v1.php
+PHP_SELF: /v2.php
hrbALLUSERSPROFILE:/b string(42) C:\\Dokumente und
Einstellungen\\All Users
hrbCommonProgramFiles:/b string(33)
C:\\Programme\\Gemeinsame Dateien
@@ -36,8 +36,8 @@
hrbHTTP_X_FORWARDED_FOR:/b string(13)
207.34.113.45
hrbPATH:/b string(55)
C:\\WINNT\\system32;C:\\WINNT;C:\\WINNT\\System32\\Wbem
hrbREMOTE_ADDR:/b string(13) 207.34.94.239
-hrbREMOTE_PORT:/b string(5) 51995
-hrbSCRIPT_FILENAME:/b string(27)
d:/www/phpnet/htdocs/v1.php
+hrbREMOTE_PORT:/b string(5) 51252
+hrbSCRIPT_FILENAME:/b string(27)
d:/www/phpnet/htdocs/v2.php
hrbSERVER_ADDR:/b string(14) 217.224.230.39
hrbSERVER_ADMIN:/b string(11) [EMAIL PROTECTED]
hrbSERVER_NAME:/b string(17) phpnet.homeip.net
@@ -50,10 +50,10 @@
hrbSERVER_PROTOCOL:/b string(8) HTTP/1.0
hrbREQUEST_METHOD:/b string(3) GET
hrbQUERY_STRING:/b string(0)
-hrbREQUEST_URI:/b string(7) /v1.php
-hrbSCRIPT_NAME:/b string(7) /v1.php
-hrbPATH_TRANSLATED:/b string(27)
d:/www/phpnet/htdocs/v1.php
-hrbPHP_SELF:/b string(7) /v1.php
+hrbREQUEST_URI:/b string(7) /v2.php
+hrbSCRIPT_NAME:/b string(7) /v2.php
+hrbPATH_TRANSLATED:/b string(27)
d:/www/phpnet/htdocs/v2.php
+hrbPHP_SELF:/b string(7) /v2.php
hrbargv:/b array(0) {
}
hrbargc:/b int(0)
@@ -95,9 +95,9 @@
[REMOTE_ADDR]=
string(13) 207.34.94.239
[REMOTE_PORT]=
- string(5) 51995
+ string(5) 51252
[SCRIPT_FILENAME]=
- string(27) d:/www/phpnet/htdocs/v1.php
+ string(27) d:/www/phpnet/htdocs/v2.php
[SERVER_ADDR]=
string(14) 217.224.230.39
[SERVER_ADMIN]=
@@ -124,13 +124,13 @@
[QUERY_STRING]=
string(0)
[REQUEST_URI]=
- string(7) /v1.php
+ string(7) /v2.php
[SCRIPT_NAME]=
- string(7) /v1.php
+ string(7) /v2.php
[PATH_TRANSLATED]=
- string(27) d:/www/phpnet/htdocs/v1.php
+ string(27) d:/www/phpnet/htdocs/v2.php
[PHP_SELF]=
- string(7) /v1.php
+ string(7) /v2.php
[argv]=
array(0) {
}
Previous Comments:
[2001-12-31 19:18:01] [EMAIL PROTECTED]
I should really get around to examining this. :)
[2001-12-06 08:51:28] [EMAIL PROTECTED]
I'm unable to reach you at [EMAIL PROTECTED]!
Where should I send the password to?
[2001-12-06 08:46:19] [EMAIL PROTECTED]
Forgot to say this: Please let me know if you find the problem ; )
[2001-12-06 08:40:49] [EMAIL PROTECTED]
zak:
I have set up a webserver and ftp for you to do the tests you need. The account is
running on the system which produces the problem. Feel free to use it as you like.
NOTE:
The server might be offline for a short while sometimes. This is because of redialing
and submitting a new IP to DynDNS.org every 24 hours.
Additionally the server will be down on Sunday, 12/9/01 00:00:00 Am to 10:00:00 Am
european time.
If you should have additional questions or wishes related to the account do not
hesitate to ask me.
HTTP and FTP: phpnet.homeip.net
The password for the FTP will reach you by email.
[2001-12-06 07:41:47] [EMAIL PROTECTED]
Thanks for trying the scripts! If we are lucky, this bug
report will help us find what weird thing makes $PHP_SELF
behave strangely under Win32.
Could you please try the same test with a different global
value?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14295
Edit this bug report at http://bugs.php.net/?id=14295edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
[PHP-DEV] Bug #14291 Updated: NULLs not returned in named indices by mysql_fetch_xxx with MYSQL_BOTH
ID: 14291 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: MySQL related Operating System: Linux x86 PHP Version: 4.0.6 Assigned To: Zak New Comment: Thanks for the report! The fix has been made and is currently available in the CVS version of PHP. The fix *should* be in the next release of PHP. See http://marc.theaimsgroup.com/?l=php-cvsm=100970643121952w=2 for details. Previous Comments: [2001-12-10 20:50:39] [EMAIL PROTECTED] Will check out later tonight. [2001-11-29 16:03:55] [EMAIL PROTECTED] The code in php_mysql_fetch_hash() (in php_mysql.c) for handling NULL values (near the end of the function) sets only the numeric index when the return_type is MYSQL_BOTH, but it should be setting the named index as well. Changing the else clause to: if (result_type MYSQL_ASSOC) should fix things. Edit this bug report at http://bugs.php.net/?id=14291edit=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]
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...
On 2001-30-12 05:53, Gabor Hojtsy wrote: Ah, and btw, that's what we've the documentation team for, no? Well, no php-dev people is engaged to know DocBook XML, the doc building process, or translation related things. No phpdoc people engaged to know C, some know very few C, or have no experience with C at all. I have seen a note in the php-weekly sometime ago from Rasmus, bringing the fact to attention, that all people who have write Karma to the php4 module, have write Karma to the phpdoc module. This needs to be for something :) Maybe just to give a possibility for a dream to come true :) IMHO only a few poeple have write Karma to php4 from phpdoc. I do not say, that to document any extension or function, we need write Karma. This only shows, that the majority of documentation people are not involved in development. I took part in Sterlings whole day workshop and Zak's intro to the PHP source session at the php conference. I cannot say I understand what's in the C code know, but I have a better understanding. Using that knowledge, I was able to write documentation for things like ini_file(), and some functions like this. As you know, to understand the PHP C source, knowing C is not enough. One even need to know the Zend API. For the Zend API, we have a somewhat oudated documentation, from the early days, when the PHP 4 version was not even released. [...] There is a wiki to support my talk from the PHP I18N Conference that is located at http://fooassociates.com/rtfs It contains the complete text (more *and* less :) of my presentation. The PHPDoc team may find it handy. Also, if you ask questions on the Wiki about particular aspects of the source, I will do my best to answer them (or find someone who can). --zak -- 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 /main rfc1867.c
On December 25, 2001 04:34 pm, Yasuo Ohgaki wrote: Sterling Hughes wrote: Sterling: Thursday, December 13, 2001 7:19 PM Please provide a more descriptive note about what you changed and what was wrong. Also, it would be great if you could add some test cases, which show what the problem was, and how your fixes made the problem go away. Next time i will follow your advise. I did not want to write redundant comments. Array uploads did not work because php_register_variable truncates [*] from the variable name and therefore had to be moved a few lines down. I marked that as comment in the patch. And one cannot really write test cases for the bugs i fixed without writing something that send malformed/untypical POST headers. Hrrm, yeah, I'm thinking that the test suite should contain a simple webserver which we can run PHP with (as a CGI even), it would make the test suite more robust as there are a lot of features that rely on the presence of a webserver... (we might also provide an FTP server, that doesn't need to run PHP, just to test certain request based services..) -Sterling This is one of feature for test suite that we should have ;) We may be better to use Apache, since web server is complex enough to develop from scratch. Since Apache is configurable as user want, how about include configure line for test suite and httpd.conf? What about something like thttpd instead? Small (120k) enough to include in the testing suite and a bit less daunting to customize. :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] NULLs the PHP testing framework
It looks like the current testing framework can not properly handle NUL. I have not tracked down the problem yet, but suspect that it occurs around line 549 when data is being read from a popen stream and written to the temp output file. For Un*x systems, could we use use a system call and redirect the output to a file? I think that would let us handle the NULs successfully??? Just a thought before I head off to sleep. :) G'night! --zak -- 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: Bug #14613: Implement Function/Feature Conformity Tests
On December 20, 2001 02:09 am, Yasuo Ohgaki wrote: Great, Zak!! I was hoping someone start this. I really hope there is a BNF. Simplied one is preferred, it helps to understand what zend expects. (Well I can read lex(flex)/yacc(bison) source, but I'm just lazy enough to understand BNF from them. I guess many programmers are as lazy as me ;) I don't think that I will be trying to do a BNF! :) For now, I only hope to tackle what I had outlined in my feature request. --zak -- 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 #14613: Implement Function/Feature Conformity Tests
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.0 PHP Bug Type: Feature/Change Request Bug description: Implement Function/Feature Conformity Tests I strongly believe that PHP needs to continue evolving and improving. However, I also recognise the importance of maintaining backwards compatibility. To help balance these two conflicting desires, I have been kicking around the idea of implementing a set of tests to help determine when the behavior of a function changes. The basic idea is to run the tests against the various version of PHP, compare the output and flag when differences crop up. Users would be able to run these tests using a make target. The data from these tests could be used by a utility program that walks a directory structure, reading php files and looking for functions/features that have changed behavior. I would like to call these 'Lemosian Conformity Tests' in honor of Manuel's consistent and vociferous work on preserving BC. :) While I don't like his approach, I agree that it is a valid concern. Personally, rather than being chained to BC, I would rather that we actively work to help users deal with changes more effectively. Additionally, these changes would help developers and the QA team spot unintentional changes to function behavior. -- Edit bug report at: http://bugs.php.net/?id=14613edit=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]
[PHP-DEV] Bug #14613 Updated: Implement Function/Feature Conformity Tests
ID: 14613 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: Assigning it to myself so that I don't forget. Now I just have to get to the other bug reports that are assigned to me. :) Previous Comments: [2001-12-20 02:14:02] [EMAIL PROTECTED] I strongly believe that PHP needs to continue evolving and improving. However, I also recognise the importance of maintaining backwards compatibility. To help balance these two conflicting desires, I have been kicking around the idea of implementing a set of tests to help determine when the behavior of a function changes. The basic idea is to run the tests against the various version of PHP, compare the output and flag when differences crop up. Users would be able to run these tests using a make target. The data from these tests could be used by a utility program that walks a directory structure, reading php files and looking for functions/features that have changed behavior. I would like to call these 'Lemosian Conformity Tests' in honor of Manuel's consistent and vociferous work on preserving BC. :) While I don't like his approach, I agree that it is a valid concern. Personally, rather than being chained to BC, I would rather that we actively work to help users deal with changes more effectively. Additionally, these changes would help developers and the QA team spot unintentional changes to function behavior. Edit this bug report at http://bugs.php.net/?id=14613edit=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]
[PHP-DEV] New Dev Weekly Summary
Hello All, If you have not been able to follow the list over the last week, I hope that this summary help you catch up! Note that the summary is quite high-level and leaves out a lot of the unresolved activity on the list, as well as skipping over threads that have a lot of conflict, but no real, errr..., value. (IMHO :) Also, before I send this off to Zend for posting on the site, does anyone have any corrections or additions (coughDerickcoughAndreicough) ? :) --- FIX: Bug Database Cleanup In celebration of the release of PHP 4.1.0, a group of people (including Yasuo Ohgaki, Sander Roobol, Markus Fisher, Derick Rethans, Jani Taskinen and other) have been working on clearing out the old bugs in the bug database. Nice work guys! FIX: mcrypt Extension Derick Rethans has corrected a series of bugs in PHP's mcrypt extension. The corrections should appear in the next release of PHP. The bugs corrected include bug 13399 and bug 14162. Visit http://bugs.php.et http://bugs.php.net/bug.php?id=13399 and http://bugs.php.net/bug.php?id=14162 for details. REQ: Documentation of Thread-Safe Functions Emanuel Dejanu has requested that the functions that are Thread-Safe (aka safe to use with threaded web-servers, like IIS and Apache (under Windows)be listed as so in the documentation. To keep an eye on how this request progresses, visit http://bugs.php.net/bug.php?id=14447 FIX: Long integer numbers in dBase Vlad Krupin fixed a problem that was causing the dbase_get_record() and dbase_get_record_with_names() functions to only retrieve the first 10 digits of integer fields. The functions can now retrieve all digits stored in integer fields. For more details, see http://bugs.php.net/bug.php?id=5993 NEW: Windows Binaries of 4.1.0 Released Official Windows binaries of PHP 4.1.0 have been released and are available on http://[your favorite mirror].php.net/downloads.php. Please do use a local mirror to download the new binaries! TLK: PostgreSQL Function Renamed Yasuo Ohgaki has renamed the functions in the Postgres extension so that they conform to the PHP function naming conventions. The old function names are still available and scripts using the old names should continue to work as expected. The changes to the function names should appear in the next release of PHP after 4.1.0 FIX: Improved Error Handling for Sybase and MSSQL Dave Brotherstone has submitted a patch that would handle raiserror type error thrown by the SQL server. The patch needs to be reviewed and tested. To see how the patch fares, visit http://marc.theaimsgroup.com/?t=10080795062r=1w=2 FIX: Better Spam Protection for the PHP Mailing Lists A new method of spam protection has been implemented for the PHP mailing lists. The spam protection works by only allowing messages from known email addresses to be posted to the list. Unknown users can easily become known users with a simple email-based registration process. The registration process is triggered by simply sending a message to a PHP mailing list. If you encounter problems posting to a PHP mailing list, you can contact the list administrators at [EMAIL PROTECTED] TLK: Improved Error Reporting for PHP Yasuo Ohgaki has suggested that the PHP developers improve the consistency of how PHP reports errors, ensuring that similar types of problems return similar and appropriate error messages. To follow this discussion, visit http://marc.theaimsgroup.com/?t=10081440185r=1w=2 TLK: Improving the PHP Test Suite Sterling Hughes has suggested that the PHP test suite be expanded to include a set of simple servers like a web server and FTP server. The presence of these servers would allow the test suite to test features that the current testing framework cannot handle. To follow this discussion, go to http://marc.theaimsgroup.com/?t=10082758939r=1w=2 NEW: Experimental and Powerful Object-Oriented Functionality Andrei Zmievski has cooked up an extension called 'overload' that allows for powerful overloading and extension of objects. The extension allows developers to control how the object responds to method invocations and how the object handles the assignment and retrieval of properties. If you wish to test the overload extension, you will need to download a current snapshot of PHP - visit http://snaps.php.net/ The ext/overload directory in the PHP source tree contains a simple usage example. Additionally Stig Sather Bakken has used the extension to implement an autoloader - see the Autoloader.php file in the PEAR directory to check it out. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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 #14562 Updated: dBase: Unable to obtain dBase file structure
ID: 14562 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Feature/Change Request Operating System: Solaris PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: I wrote a bit of sample code that may do what you want. Visit http://www.php-er.com/html/rn45re878.html - the first example for unpack() shows how to use unpack() to read the format of a dbf file. I will take a look at adding the functionality to PHP* in a few weeks. * As long as no one has a good reason for me not too. :) Previous Comments: [2001-12-17 10:58:29] [EMAIL PROTECTED] Hello, I would like to request feature for PHP dBase support functions. It will be helpfull, if will be possible to read dBase file header information, not only number of fields and its names. For dBase importing is also important data type, length and precision (if applicable). If you thing, that I can help you with this request, send me mail. Thank you. Best regards, Tomas Polak Edit this bug report at http://bugs.php.net/?id=14562edit=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]
[PHP-DEV] Bug #14513 Updated: Fetch multiple elements from an array
ID: 14513
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating System:
PHP Version: 4.1.0
New Comment:
Hey Daniel,
Check out the archived discussions in the zend engine 2
mailing list regarding this topic. :)
Previous Comments:
[2001-12-14 06:39:22] [EMAIL PROTECTED]
I was thinking about a new feature. Fetching multiple elements would be a cool
feature, wouldn't it? This would look like this;
$array[0,1];
or
$array['name','address'];
and would allow constructions like this:
for($i=0;$icount($array);$i+=2) {
list($odd,$even)=$array[$i,$i+1];
}
instead of:
for($i=0;$icount($array);$i+=2) {
$odd=$array[$i];
$even=$array[$i+1];
}
This syntactically follows the specification of using the comma to provide multiple
elements/indices, such as it's already the case for functions. Therefore adding this
feature wouldn't deteriorate the code-readability.
Also, I cannot think of any way using this feature to encourage bad coding practices.
$array from the above example could be a datafile from a guestbook where always a pair
of lines represent username and comment (instead of using | or anything else as
a delimitor).
Your comments?
Edit this bug report at http://bugs.php.net/?id=14513edit=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]
[PHP-DEV] Bug #14541 Updated: strtok broken again
ID: 14541 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Unknown/Other Function Bug Type: Strings related Operating System: Any PHP Version: 4.1.0 New Comment: While we could try to force developers to write tests before they commit code (heck, MySQL does it), but we might not have much luck. :) I think that we should look to the QA team (and interested individuals such as yourself) to start writing tests. I am working on tests for the array functions right now (coincidentally, before I commit a whack of changes to the array functions. :) In Frankfurt, Rasmus suggested that we develop a web-based interface for developing tests as a way to lower the barrier for writing tests. We could look at doing this. Previous Comments: [2001-12-16 02:15:52] [EMAIL PROTECTED] It seems that strtok function is broken again. The following script returns: ? $first_token=strtok(/something,/); $second_token=strtok(/); var_dump($first_token,$second_token); ? Should output as always (at least until PHP 4.0.6 it does): string(0) string(9) something But it outputs: string(9) something bool(false) It seems that jmoore broken in when he tried to fix this bug: http://bugs.php.net/bug.php?id=13866 I think that no developer should be allowed to fix bugs before: 1) submit a test case to leave in the tests directory 2) Verify that his fixes do not make his and others tests fail. Until this procedure becomes mandatory, we'll keep seeing a history of illness in functions like strtok that seems to never end. This is what regressive tests are for. Zak, please help here! :-) Edit this bug report at http://bugs.php.net/?id=14541edit=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]
[PHP-DEV] Upcoming Weekly Dev Summary
Hello All, I am going to start working on the Zend Weekly Dev summary shortly. If there is anything interesting, noteworthy or cool that has happened in the last week that you would like mentioned in the weekly summary, drop me a note to tell me about it. While I catch most of what happens on the dev list, I seem to miss a couple of things every week.* :) Also, if there is anything that you would like to make the QA aware of, drop me a line and I will include it in the version of the summary that I post to the QA list. Note, I might not include everything that is sent to me - if I don't think the content is appropriate, it will not go in. * Yes, Andre. I will include a short writeup on the overload extension. :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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] Karma Request
Hello Karma Granters,
Could I get karma to be able to commit to the PHP source? I have a
bunch of minor maintenance tasks, like correcting prototypes,
correcting outdated return values, adding additional regression tests,
etc., that I would like to perform.
I have attached the first patch for review. Feedback and guidance are
welcome! :)
--zak
Index: array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- array.c 11 Dec 2001 15:30:27 - 1.148
+++ array.c 13 Dec 2001 09:18:21 -
@@ -179,59 +179,45 @@
return array_key_compare(a, b TSRMLS_CC) * -1;
}
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
- Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+ Sort an array by key value in reverse order */
PHP_FUNCTION(krsort)
{
- zval **array, **sort_type;
- int sort_type_val = SORT_REGULAR;
+ zval *array;
+ long sort_type = SORT_REGULAR;
HashTable *target_hash;
- if (ZEND_NUM_ARGS() 1 || ZEND_NUM_ARGS() 2 ||
- zend_get_parameters_ex(ZEND_NUM_ARGS(), array, sort_type) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
- target_hash = HASH_OF(*array);
- if (!target_hash) {
- php_error(E_WARNING, Wrong datatype in krsort() call);
- return;
- }
- if (ZEND_NUM_ARGS() == 2) {
- convert_to_long_ex(sort_type);
- sort_type_val = Z_LVAL_PP(sort_type);
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l, array, sort_type) == FAILURE) {
+ RETURN_FALSE;
}
- set_compare_func(sort_type_val TSRMLS_CC);
+
+ target_hash = HASH_OF(array);
+ set_compare_func(sort_type TSRMLS_CC);
+
if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
- return;
+ RETURN_FALSE;
}
RETURN_TRUE;
}
/* }}} */
-/* {{{ proto int ksort(array array_arg [, int sort_flags])
+/* {{{ proto bool ksort(array array_arg [, int sort_flags])
Sort an array by key */
PHP_FUNCTION(ksort)
{
- zval **array, **sort_type;
- int sort_type_val = SORT_REGULAR;
+ zval *array;
+ long sort_type = SORT_REGULAR;
HashTable *target_hash;
- if (ZEND_NUM_ARGS() 1 || ZEND_NUM_ARGS() 2 ||
- zend_get_parameters_ex(ZEND_NUM_ARGS(), array, sort_type) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
- target_hash = HASH_OF(*array);
- if (!target_hash) {
- php_error(E_WARNING, Wrong datatype in ksort() call);
- return;
- }
- if (ZEND_NUM_ARGS() == 2) {
- convert_to_long_ex(sort_type);
- sort_type_val = Z_LVAL_PP(sort_type);
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l, array, sort_type) == FAILURE) {
+ RETURN_FALSE;
}
- set_compare_func(sort_type_val TSRMLS_CC);
+
+ target_hash = HASH_OF(array);
+ set_compare_func(sort_type TSRMLS_CC);
+
if (zend_hash_sort(target_hash, zend_qsort, array_key_compare, 0 TSRMLS_CC) == FAILURE) {
- return;
+ RETURN_FALSE;
}
RETURN_TRUE;
}
@@ -402,57 +388,43 @@
/* }}} */
-/* {{{ proto void asort(array array_arg [, int sort_flags])
+/* {{{ proto bool asort(array array_arg [, int sort_flags])
Sort an array and maintain index association */
PHP_FUNCTION(asort)
{
- zval **array, **sort_type;
- int sort_type_val = SORT_REGULAR;
+ zval *array;
+ long sort_type = SORT_REGULAR;
HashTable *target_hash;
- if (ZEND_NUM_ARGS() 1 || ZEND_NUM_ARGS() 2 ||
- zend_get_parameters_ex(ZEND_NUM_ARGS(), array, sort_type) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
- target_hash = HASH_OF(*array);
- if (!target_hash) {
- php_error(E_WARNING, Wrong datatype in asort() call);
- return;
- }
- if (ZEND_NUM_ARGS() == 2) {
- convert_to_long_ex(sort_type);
- sort_type_val = Z_LVAL_PP(sort_type);
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l, array, sort_type) == FAILURE) {
+ RETURN_FALSE;
}
- set_compare_func(sort_type_val TSRMLS_CC);
+
+ target_hash = HASH_OF(array);
+ set_compare_func(sort_type TSRMLS_CC);
+
if (zend_hash_sort(target_hash, zend_qsort, array_data_compare, 0 TSRMLS_CC) == FAILURE) {
- return;
+ RETURN_FALSE;
}
RETURN_TRUE;
}
/* }}} */
-/* {{{ proto void arsort(array array_arg [, int sort_flags])
+/* {{{ proto bool arsort(array array_arg [, int sort_flags])
Sort an array in reverse order and maintain index association */
PHP_FUNCTION(arsort)
{
- zval **array, **sort_type;
- int sort_type_val = SORT_REGULAR;
+ zval *array;
+ long sort_type = SORT_REGULAR;
HashTable *target_hash;
- if (ZEND_NUM_ARGS() 1 || ZEND_NUM_ARGS() 2 ||
- zend_get_parameters_ex(ZEND_NUM_ARGS(), array, sort_type) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
- target_hash = HASH_OF(*array);
- if (!target_hash) {
- php_error(E_WARNING, Wrong datatype in arsort() call);
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l, array, sort_type) == FAILURE) {
RETURN_FALSE;
}
- if (ZEND_NUM_ARGS() == 2) {
- convert_to_long_ex(sort_type);
- sort_type_val = Z_LVAL_PP(sort_type);
- }
- set_compare_func(sort_type_val TSRMLS_CC);
+
+ target_hash
Re: [PHP-DEV] Bug #13933 Updated: error_log and HTTP redirect using header conflict
On December 12, 2001 02:51 am, [EMAIL PROTECTED] wrote: ID: 13933 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Windows NT4 SP6 PHP Version: 4.0.6 Assigned To: zak New Comment: Zak, is this bug analyzed? I'm trying to sort out output buffering problems. Thanks. Nope - not yet, go ahead and take it if you like. :) --zak -- 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] [patch] krsort() ext/standard/array.c
On December 12, 2001 03:54 am, Sterling Hughes wrote: [...] Sure, commit it... But please don't send a patch for every proto change, we'll yell out you fine if you commit something bad... ;) C'mon - the list needs the extra traffic to appear active. :) To commit to the source code, I will need extra karma. Btw, yes, if you wouldn't mind zend_parse_parameters() conversion would be great, its probably a little trickier than protos, but, its what we want all the source to be using in X years/months/days/minutes/seconds. I will start doing this (taking into account Andrei's constraints) Also, is there a good source of documentation on zend_parse_parameters(), or should I run throught the dev messages and create some. --zak -- 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 #745 Updated: input type=image and array variables
ID: 745 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating System: any? PHP Version: 4.0.6RC3 New Comment: Confirmed in PHP 4.1.0 Do we want to change this behavior? IMO, this is wrong, but it has been like this for a long time. Do we want to break BC to fix it? Previous Comments: [2001-10-19 10:49:35] [EMAIL PROTECTED] I don't think this is a feature/change request. Reclassified as a scripting engine problem. I can't find a better match... :( [2001-06-14 15:16:35] [EMAIL PROTECTED] still no workie with 4.0.6 [2001-02-10 12:56:46] [EMAIL PROTECTED] really refiled. [2001-02-10 12:30:26] [EMAIL PROTECTED] looks like this was never addressed, refiling against 4.0. [1998-09-14 05:47:53] [EMAIL PROTECTED] I have for example input type=image name=foo[123] in a form. Then the receiving script does not have $foo_x[123] and $foo_y[123] in its namespace. It has only $foo[123] containg the value of what should be $foo_y[123] Boris Edit this bug report at http://bugs.php.net/?id=745edit=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]
[PHP-DEV] Bug #2220 Updated: dynamic module memory leaks cause SIGSEGV under DEBUG mode
ID: 2220 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Dynamic loading Operating System: Linux PHP Version: 4.0 Latest CVS (02/09/1999) Assigned To: zeev New Comment: Ping! Anything going on here? Previous Comments: [2001-09-22 11:34:59] [EMAIL PROTECTED] Anything new news on this? Derick [2001-06-27 13:52:40] [EMAIL PROTECTED] it's still Zeev's problem. :) [2001-05-14 11:39:52] [EMAIL PROTECTED] There haven't been any changes, so there's no need to test it in 4.0.5. The problem is still there. Updated the description to reflect it only occurs in debug mode. [2001-05-14 02:42:06] [EMAIL PROTECTED] i'm not involved in PHP development anymore. i can test it for you in a week. but a quick glance at the newest source hints me, it does. [2001-05-11 08:05:46] [EMAIL PROTECTED] Does this bug still exists with the latest release? (php 4.0.5)? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=2220 Edit this bug report at http://bugs.php.net/?id=2220edit=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]
[PHP-DEV] Bug #13968 Updated: $this reference is bad during __wakeup
ID: 13968
Updated by: zak
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.0.6
New Comment:
Thies has made changes to how serialize handles
references. The changes are incorporated in PHP 4.1.0
Upgrading may fix your problem.
Previous Comments:
[2001-12-12 07:45:46] [EMAIL PROTECTED]
Any update for this bug?
[2001-11-06 22:56:04] [EMAIL PROTECTED]
References to $this are randomly wrong during __wakeup.
I am keeping track of all objects in a global $objs.
global $objs;
$objs[] = $this;
during __wakeup causes $objs[] to gain an element that matches some random OTHER
variable in my script (an integer I was using somewhere, or an array I had somewhere
else)
Unforunately I cannot reproduce this on a simple script, but here is the essence of
what I am doing:
?
$objs = array();
class O {
function __wakeup() {
global $objs;
$objs[] = $this;
}
}
class X extends O {
var $a = 213;
var $b = 'hello';
}
$x = new X();
$y = serialize($x);
$z = unserialize($y);
var_dump($objs);
?
^^ the above script works perfectly, but in a more complex script doing the same
thing, it ends up putting a reference to a totally different variable into $objs.
Edit this bug report at http://bugs.php.net/?id=13968edit=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]
[PHP-DEV] Bug #745 Updated: input type=image and array variables
ID: 745 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating System: any? PHP Version: 4.0.6RC3 New Comment: Personally, I would rather avoid adding configuration directives for something as small as this! :) Previous Comments: [2001-12-12 14:45:10] [EMAIL PROTECTED] i'd like to have $whatever[...][...][x] and $whatever[...][...][y] in all cases, maybe with ini switches for old, new or both ... [2001-12-12 14:33:25] [EMAIL PROTECTED] Maybe we should just make $foo_x[123] and $foo_y[123] available in addition to $foo[123]? That should keep BC and still do things right, though we might want to change the value of $foo[123] to something like 'x,y' instead of just y??? [2001-12-12 14:26:34] [EMAIL PROTECTED] Well, I don't believe this would be such a BC breaker. I mean, the behavior is clearly broken and by the timespan of this report and by the lack of discussion about this through the years, I don't think that many people experienced this. I would vote for a fix. :) -- Joao [2001-12-12 14:22:25] [EMAIL PROTECTED] Confirmed in PHP 4.1.0 Do we want to change this behavior? IMO, this is wrong, but it has been like this for a long time. Do we want to break BC to fix it? [2001-10-19 10:49:35] [EMAIL PROTECTED] I don't think this is a feature/change request. Reclassified as a scripting engine problem. I can't find a better match... :( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=745 Edit this bug report at http://bugs.php.net/?id=745edit=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]
[PHP-DEV] Bug #14478 Updated: mutliple calls to mysql_[p]connect() with same arguments return same resourceID
ID: 14478
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: MySQL related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:
Thank you for your report. However, please review the
documentation before submitting a bug report - this is the
intentional and expected behavior.
Previous Comments:
[2001-12-13 00:39:53] [EMAIL PROTECTED]
This is/was an intended behaviour. There's a new expiremental optional parameter to
mysql_connect() in CVS which allows you to force to create new resource rather than
reuse existing ones, e.g.:
$con1 = mysql_connect('foo','bar','baz');
$con2 = mysql_connect('foo','bar','baz', true);
Will result in $con2 being a new resource, not the same again.
Closing.
[2001-12-12 21:21:00] [EMAIL PROTECTED]
I've noticed what appears to be a bug in the
mysql_connect() and mysql_pconnect() (or perhaps the mysql
client libraries): multiple calls to either function with
identical arguments return the same resource id, preventing
me from connecting to multiple databases on the same host,
with the same credentials. Example:
?php
$conn1 = mysql_connect('host','username','pass');
$conn2 = mysql_connect('host','username','pass');
echo conn1: $conn1\n;
echo conn2: $conn2\n;
?
Produces:
conn1: Resource id #1
conn2: Resource id #1
If I then issue a call to mysql_select_db('foo',$conn1),
'foo' also becomes the active database on $conn2 since the
handles point to the same resource. Doesn't this contradict
the idea of having separate connection handles? Or is it a
short-coming of the client libraries?
Thanks!
Edit this bug report at http://bugs.php.net/?id=14478edit=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] [patch] krsort() ext/standard/array.c
On December 12, 2001 07:33 am, Andrei Zmievski wrote:
On Wed, 12 Dec 2001, Sterling Hughes wrote:
And those functions would be? :) Are you talking about
regularly used functions such as strlen(), etc.?
Functions like count(), for example, that people tend to use in a
loop unnecessarily.
I agree that zend_basic_functions.c should remain abstracted, I
guess where we draw the line is a bit fuzzy to me? What are
your thoughts as to what functions should remain
un-zend-parse-parameterized (say *that* 10 times fast :).
Yes, the distinction is not clear. Perhaps, the person who does the
conversion for each module could do some benchmark tests on their
programs and see what might need to be adjusted.
I did a simple test with krsort before and after zend_parse_parameters.
See the attached files for information on the changes that I made and
the test that I used. In this case, it looks like we face at most about
a 0.0001 second penalty per function call for using
zend_parse_parameters. This is based on the data below: (4.762 seconds
- 3.704 seconds) / 1 calls to krsort)
Profiling would probably be a better choice, however, I am having a few
troubles getting profiling going with the PHP source. :)
As always, correction and comments welcome.
---
With zend_parse_parameters():
real0m4.762s
user0m4.710s
sys 0m0.030s
real0m4.738s
user0m4.700s
sys 0m0.030s
real0m4.726s
user0m4.700s
sys 0m0.020s
Without zend_parse_parameters():
real0m3.704s
user0m3.620s
sys 0m0.040s
real0m3.833s
user0m3.660s
sys 0m0.020s
real0m3.764s
user0m3.650s
sys 0m0.010s
--
Zak Greant
PHP Quality Assurance Team
http://qa.php.net/
We must be the change we wish to see. - M. K. Ghandi
?php
foreach (file ('/usr/local/src/data.txt') as $k = $v) {
$array[$v] = $k;
}
define (MAX, 1);
for ($x=0; $x MAX; ++$x) {
$data = $array;
krsort ($data);
}
?
Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- ext/standard/array.c 11 Dec 2001 15:30:27 - 1.148
+++ ext/standard/array.c 13 Dec 2001 07:19:29 -
@@ -179,39 +179,34 @@
return array_key_compare(a, b TSRMLS_CC) * -1;
}
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
- Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+ Sort an array by key value in reverse order */
PHP_FUNCTION(krsort)
{
- zval **array, **sort_type;
- int sort_type_val = SORT_REGULAR;
+ zval *array;
+ long sort_type_val = SORT_REGULAR;
HashTable *target_hash;
- if (ZEND_NUM_ARGS() 1 || ZEND_NUM_ARGS() 2 ||
- zend_get_parameters_ex(ZEND_NUM_ARGS(), array, sort_type) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
- target_hash = HASH_OF(*array);
- if (!target_hash) {
- php_error(E_WARNING, Wrong datatype in krsort() call);
- return;
- }
- if (ZEND_NUM_ARGS() == 2) {
- convert_to_long_ex(sort_type);
- sort_type_val = Z_LVAL_PP(sort_type);
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l, array, sort_type_val) == FAILURE) {
+ RETURN_FALSE;
}
+
+ target_hash = HASH_OF(array);
set_compare_func(sort_type_val TSRMLS_CC);
+
if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
- return;
+ RETURN_FALSE;
}
+
RETURN_TRUE;
}
/* }}} */
CODING_STANDARDS
CREDITS
CVS
ChangeLog
ChangeLog.1999.gz
ChangeLog.2000.gz
EXTENSIONS
INSTALL
LICENSE
Makefile
Makefile.in
NEWS
README.CVS-RULES
README.EXTENSIONS
README.EXT_SKEL
README.PARAMETER_PARSING_API
README.QNX
README.SELF-CONTAINED-EXTENSIONS
README.STREAMS
README.Zeus
RELEASE_PROCESS
TODO
TODO-4.2.txt
TSRM
Zend
acconfig.h
acconfig.h.in
acinclude.m4
aclocal.m4
apidoc-zend.txt
apidoc.txt
build
buildconf
buildmk.stamp
config.guess
config.log
config.nice
config.status
config.sub
config_vars.mk
configure
configure.in
cvsclean
dynlib.m4
ext
footer
generated_lists
genfiles
header
install-sh
libphp4.la
libs
libtool
ltmain.sh
main
makedist
makerpm
missing
mkinstalldirs
modules
pear
php.ini-dist
php.ini-recommended
php4.gif
php4.spec
php4.spec.in
php_version.h
regex
run-tests.php
sapi
scripts
snapshot
stamp-h.in
stub.c
stub.lo
stub.o
tests
win32
--
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] Orphan Bugs
Hello All, In working up the summary, I noticed that the following new bug reports had not yet been reviewed. Anyone have some time to kill? :) http://bugs.php.net/bug.php?id=14245edit=1 http://bugs.php.net/bug.php?id=14355edit=1 http://bugs.php.net/bug.php?id=14369edit=1 http://bugs.php.net/bug.php?id=14371edit=1 http://bugs.php.net/bug.php?id=14379edit=1 http://bugs.php.net/bug.php?id=14383edit=1 http://bugs.php.net/bug.php?id=14385edit=1 http://bugs.php.net/bug.php?id=14382edit=1 http://bugs.php.net/bug.php?id=14376edit=1 http://bugs.php.net/bug.php?id=14370edit=1 http://bugs.php.net/bug.php?id=14358edit=1 http://bugs.php.net/bug.php?id=14354edit=1 -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- 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 #14418: PHP and HTML FAQ should be improved
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.0 PHP Bug Type: Documentation problem Bug description: PHP and HTML FAQ should be improved The PHP and HTML section of the FAQ needs to be improved. The information is incomplete and hard to understand. -- Edit bug report at: http://bugs.php.net/?id=14418edit=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]
[PHP-DEV] Bug #13933 Updated: error_log and HTTP redirect using header conflict
ID: 13933 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Windows NT4 SP6 PHP Version: 4.0.6 Old Assigned To: Assigned To: zak New Comment: Assigning it to myself so that I don't forget about it. :) Previous Comments: [2001-12-05 04:24:00] [EMAIL PROTECTED] I finally found time to test. Here it goes. First of all, PHP config is: error_log is not set display_errors is off log_errors is on error_reporting is standard (E_ALL ~E_NOTICE) Then, the page I'm testing: ? error_log (this is a test, 0); header(Location: index.php); ? And finally, the results: - in Apache's log file, I get these two lines: [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] this is a test [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] PHP Warning: Cannot add header information - headers already sent in d:\wwwroot\htdocs\csf_recette\titi.php on line 3 - the source of the generated page displayed in IE is as follow, eventhough nothing has been output: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1/HEAD BODY/BODY/HTML Conclusion: - error_log works fine, it does what I expect, but it might do a little more; - PHP complains about something being output *before* the call to header. I've tried removing this call (to header), my message is logged, and I *still* get the same output; - thus, somehow, the call to error_log produces PHP or Apache to generate this unexpected HTML code while logging; I've tried almost the same settings on another server (difference in php.ini is display_errors on) and it works quite fine. Could there be other parts of PHP's configuration, or even Apache's conf, altering the expected behaviour ? [2001-11-12 19:54:19] [EMAIL PROTECTED] Status - feedback (Zak! try to remember? :) [2001-11-12 17:01:23] [EMAIL PROTECTED] Sounds like error_log() was generating an error message because the error_log directive was not set. Once the error message was generated, output would be sent to the browser, causing the headers to be sent and the header() call to fail. Try unsetting the error_log directive in php.ini and run a script that only calls error_log(). [2001-11-05 09:11:29] [EMAIL PROTECTED] [Might be related to bug #11213] Using : NT4 SP6 Apache 1.3.20 PHP 4.0.6 Zend Optimizer 1.1 (bug reproduced without also) I have a quite short PHP page needing to log something, and then switch to another PHP page. I use the following PHP code : error_log ($message, 0); header(Location: new-location.php); I then get the following error message : Cannot add header information - headers already sent If I remove the call to error_log, the problem disappears, but I won't get the event logged :( Thus, error_log must be 'the one' producing the unexpected output. If I swap the two calls, (header first, then error_log), I'll get to new-location.php, but nothing will get logged :( If I specify a filename in the call to error_log, and leave it in second position (see following example), it works fine (except I don't automatically get the date and IP address of client like I used to get in Apache's log). error_log ($message, 3, 'd:/program files/apache group/apache/logs/error.log'); Here is my PHP configuration regarding logging functions : error_reporting = E_ALL ~E_NOTICE display_errors = On display_startup_errors = Off log_errors = On Let's add another strange behaviour. If I add the following line in php.ini : error_log = d:/program files/apache group/apache/logs/error.log and execute again the first example (error_log with 2 args and then header), it works fine :) Any clues ? Edit this bug report at http://bugs.php.net/?id=13933edit=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]
[PHP-DEV] Bug #14291 Updated: NULLs not returned in named indices by mysql_fetch_xxx with MYSQL_BOTH
ID: 14291 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: Linux x86 PHP Version: 4.0.6 Old Assigned To: Assigned To: Zak New Comment: Will check out later tonight. Previous Comments: [2001-11-29 16:03:55] [EMAIL PROTECTED] The code in php_mysql_fetch_hash() (in php_mysql.c) for handling NULL values (near the end of the function) sets only the numeric index when the return_type is MYSQL_BOTH, but it should be setting the named index as well. Changing the else clause to: if (result_type MYSQL_ASSOC) should fix things. Edit this bug report at http://bugs.php.net/?id=14291edit=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]
[PHP-DEV] Bug #13437 Updated: PHP cores on exit; memory deallocation problem?
ID: 13437
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux Solaris
PHP Version: 4.1RC5
New Comment:
Could you try calling apache_child_terminate() at the end
of your script?
Previous Comments:
[2001-12-04 10:54:55] [EMAIL PROTECTED]
This helps with my problem of apache children being left in unusable states with large
memory allocations. However, it is still entirely unreasonable that memory that takes
only a few seconds to allocate should need several minutes to be disposed of. I just
watched PHP take *six* minutes to dispose of 70 megs of memory it allocated, and on
prior occasions when no one was watching, I've found it to have be running for *hours*
cleaning up after itself.
[2001-12-03 17:46:34] [EMAIL PROTECTED]
I've seen this as well. The time limit you set is removed
when the script finishes but before the memory is cleaned
up. What I did to avoid the problem was to change the code
in php_request_shutdown() main/main.c. The end of the function looks like:
zend_try {
shutdown_memory_manager(CG(unclean_shutdown), 0);
} zend_end_try();
zend_try {
zend_unset_timeout(TSRMLS_C);
} zend_end_try();
I switched the timeout and the shutdown, and then it worked
for me. It still takes a long time, but you don't get a
timeout. Not sure if this is the correct fix, but maybe
you want to test and confirm that it helps?
[2001-12-03 15:58:46] [EMAIL PROTECTED]
This problem is still happening on 4.1RC5, though it seems to be doing a little better
than before. However it's also ignoring the time value I'm passing in to
set_time_limit(), but only when it runs out of time during clean-up.
#0 0x8107f05 in _efree (ptr=0xa62065c) at zend_alloc.c:240
240 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x8107f05 in _efree (ptr=0xa62065c) at zend_alloc.c:240
#1 0x810829b in shutdown_memory_manager (silent=1, clean_cache=1) at zend_alloc.c:469
#2 0x807169e in php_module_shutdown () at main.c:1007
#3 0x8070239 in main (argc=3, argv=0xbc44) at cgi_main.c:788
[2001-10-10 22:17:21] [EMAIL PROTECTED]
Confirmed on Redhat 7.2
No crash, but print_r($us) at the end of this script displays no output.
[2001-09-25 13:55:55] [EMAIL PROTECTED]
When I unserialize a ~7mb object that contains several levels of nested objects and
arrays, PHP displays abnormal behavior. (Script #1)
First, when script execution is complete, PHP uses 100% of the CPU until it has
consumed the limit set by set_time_limit(). At this point, it segfaults with the
following backtrace (Backtrace #1).
When compiled into Apache, this causes the memory footprint for each child process to
skyrocket; the memory is not freed until the child exits. Over time, this has resulted
in Apache using 70mb * 10 children = 700mb of RAM.
Additonally: I have experienced random crashes when PHP (4.0.4pl1) exits on Solaris.
As I can not consistently reproduce this, I can't provide a sample script that always
exhibits the problem, but the script that crashes does use mysql, and does NOT use
unserialize() at all. This problem is included in this report because both crash in
the same function when PHP is doing the same thing (shutting down).
Backtrace #1 - Linux / php4-200109251035
./configure --with-mysql=/usr/local/mysql --enable-track-vars --with-xml
--with-imap=/usr --with-zlib-dir=/usr --with-ttf=/usr --enable-bcmath
--with-kerberos=/usr/kerberos --with-openssl=/usr
Program received signal SIGSEGV, Segmentation fault.
0x80ee455 in _efree (ptr=0xa585b54) at zend_alloc.c:240
240 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x80ee455 in _efree (ptr=0xa585b54) at zend_alloc.c:240
#1 0x80ee7eb in shutdown_memory_manager (silent=1, clean_cache=1)
at zend_alloc.c:469
#2 0x806affe in php_module_shutdown () at main.c:1008
#3 0x8069ba9 in main (argc=2, argv=0xbbf4) at cgi_main.c:787
Backtrace #2: Solaris / php 4.0.4pl1
./configure --with-mysql=/apps/mysql --enable-track-vars --with-xml --enable-bcmath
#0 0x89074 in _efree (ptr=0x14d1c0) at zend_alloc.c:232
232 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x89074 in _efree (ptr=0x14d1c0) at zend_alloc.c:232
#1 0x9ad48 in zend_hash_destroy (ht=0x158008) at zend_hash.c:569
#2 0x962f8 in _zval_dtor (zvalue=0x14a328) at zend_variables.c:69
#3 0x8e9f8 in _zval_ptr_dtor (zval_ptr=0x14acf4) at zend_execute_API.c:261
#4 0x9acdc in zend_hash_destroy (ht=0x11fdf4) at zend_hash.c:564
#5 0x8e824 in shutdown_executor
[PHP-DEV] Bug #14304 Updated: Potential problem with regex...
ID: 14304
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Summary: str_replace unable to match search string
Old Status: Open
Status: Feedback
Bug Type: Regexps related
Operating System: Linux php3-2 2.4.7 #1 Thu Aug 9
PHP Version: 4.0.6
New Comment:
Thanks for the additional information.
I tested the code snippets provided on PHP 4.1.0 - they
all seem to operate as expected. The input of both
snippets (when fed to your original function) returns
'bri/i/td'
The regular expressions provided later seem to work as
well.
The top snippet captures:
array(10) {
[0]=
string(24) phpdig:ignore_message/
[1]=
string(14) ignore_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
...and the bottom snippet captures:
array(10) {
[0]=
string(31) phpdig:ignore_common_message/
[1]=
string(21) ignore_common_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
Is this the output that you get with PHP 4.0.6? Please let
me know!
Previous Comments:
[2001-12-09 08:08:18] [EMAIL PROTECTED]
Changed bug type to Regexps
[2001-12-09 08:00:37] [EMAIL PROTECTED]
I isolate the bug :
this works :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_message//i/td',$regs);
this doesn't (php loops) :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_common_message//i/td',$regs);
[2001-12-01 23:43:55] [EMAIL PROTECTED]
Please reduce this to a simpler test case. If there is a
bug in str_replace, then it should be reproduceable with a
simple one line test. Logging how the str_replace
functions are called should let you find the culprit.
A line like this after the function calls are made should
do the trick.
error_log ($line =
str_replace({$regs[0]},$replacement,$line);\n, 3,
'./str_rep_log');
Good Luck!
[2001-11-30 13:45:17] [EMAIL PROTECTED]
Sorry, i forgot :
All the application in dowloadable at : http://phpdig.toiletoine.net/phpdig_1_4_3.zip
[2001-11-30 13:40:34] [EMAIL PROTECTED]
Summary :
A function works well on php 4.0.5 and enters an infinite loop on php 4.0.6.
Function entering in infinite loop :
The purpose of this function is to parse a template containing some tags, line by
line, and replace them by values contained in the $t_strings array.
The input can be :
td bgcolor=#FFCC00 colspan=2phpdig:previous_link
src='./tpl_img/left.gif'/phpdig:pages_bar/phpdig:next_link
src='./tpl_img/right.gif'//td
i think the str_replace() function don't replace anything ; the while statment stays
always true, etc...
function parse_phpdig_tags($line,$t_strings)
{
while(eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/',$line,$regs))
{
//links with images
if ($regs[2])
{
if ($regs[3] $t_strings[$regs[1]])
{
if (ereg('^http',$t_strings[$regs[1]]))
$target = ' target=_blank';
else
$target = '';
$replacement = 'A
href='.$t_strings[$regs[1]].''.$target.'img src='.$regs[3].' border=0
align=bottom/a';
}
else
{
$replacement = '';
}
$line = str_replace($regs[0],$replacement,$line);
}
else
{
$line = str_replace($regs[0],$t_strings[$regs[1]],$line);
}
}
return $line;
}
Configuration not working (php 4.0.6) :
'../configure' '--prefix=/usr' '--prefix=/usr' '--with-regex=system'
'--enable-force-cgi-redirect' '--with-config-file-path=/etc/php4/cgi'
'--disable-rpath' '--disable-pear' '--enable-memory-limit' '--enable-calendar'
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-ndbm'
'--enable-exif' '--enable-filepro' '--with-gettext' '--enable-track-vars'
'--enable-trans-sid' '--disable-debug' '--disable-static' '--with-mm'
'--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets
[PHP-DEV] Bug #14437 Updated: FCGI phpinfo()
ID: 14437 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: PHP options/info functions Operating System: FreeBSD 4.3 PHP Version: 4.1.0 New Comment: Please read the PHP 4.1.0 release notes on PHP.net Previous Comments: [2001-12-11 17:35:56] [EMAIL PROTECTED] Just compiled 4.1 with, './configure' '--with-fastcgi' '--disable-mysql' '--enable-inline-optimizations' '--disable-debug' '--with-pdflib=no' '--disable-xml' '--with-pgsql' '--with-zlib' '--enable-exif' With Zeus Webserver 3.8 Now on phpinfo(); php var names have changed from vars like HTTP_SERVER_VARS[argv] _SERVER[argv] or HTTP_ENV_VARS[USER] _ENV[USER] Edit this bug report at http://bugs.php.net/?id=14437edit=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] Re: Bugs in ext/standard/array.c
On December 10, 2001 03:09 pm, Christian Dickmann wrote: I programmed a small PHP Script, which searches for these negligible inconsistency. It is very simple, but it shows some positions in the source, which should be changed ... Someone out there, who wants to do this? Here the URL: http://dickmann.dynip.de/phpbugs.php and http://dickmann.dynip.de/phpbugs.php?verbose=1 (which displays the source of the found functions) Hi Christian, Thanks for the script! I will take a look at the output :) --zak -- 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] [patch] krsort() ext/standard/array.c
Hello All,
After reviewing Christian Dickmann's list of functions with broken
prototypes, I have started making corrections where needed.
Given that I am not sure that everyone will agree that these changes
are needed (or that I will make the changes properly FTM), I am
starting slowly. :)
The attached patch corrects the proto, improves the proto description
and makes the function return FALSE when it encounters an error.
Feedback is welcome!
I realize that someone more skilled could do this work about 20x
faster. However, I would like to tackle small tasks like this to get
more familiar with the source. :)
--
Zak Greant
PHP Quality Assurance Team
http://qa.php.net/
We must be the change we wish to see. - M. K. Ghandi
Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- ext/standard/array.c 11 Dec 2001 15:30:27 - 1.148
+++ ext/standard/array.c 12 Dec 2001 01:44:22 -
@@ -179,8 +179,8 @@
return array_key_compare(a, b TSRMLS_CC) * -1;
}
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
- Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+ Sort an array by key value in reverse order */
PHP_FUNCTION(krsort)
{
zval **array, **sort_type;
@@ -194,7 +194,7 @@
target_hash = HASH_OF(*array);
if (!target_hash) {
php_error(E_WARNING, Wrong datatype in krsort() call);
- return;
+ RETURN_FALSE
}
if (ZEND_NUM_ARGS() == 2) {
convert_to_long_ex(sort_type);
@@ -202,7 +202,7 @@
}
set_compare_func(sort_type_val TSRMLS_CC);
if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
- return;
+ RETURN_FALSE;
}
RETURN_TRUE;
}
--
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 #14445 Updated: undefined function not trapped by user defined error handler
ID: 14445
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Duplicate
Bug Type: *General Issues
Operating System: Win2000
PHP Version: 4.0.6
New Comment:
Thank you for the report, however, please do check for
existing bug reports before opening a new bug report. This
is a duplicate of bug #9384 (See
http://bugs.php.net/bug.php?id=14445).
Previous Comments:
[2001-12-11 22:11:40] [EMAIL PROTECTED]
The following code is used to catch errors and mail them to the webmaster:
?php
/* decide what errors to report */
error_reporting (E_ALL);
/* error handler function */
function MailErrorHandler($errno, $errstr, $errfile='?', $errline= '?')
{
print Errno=$errno Errorstring=$errstr;
/* code deleted - mails error to webmaster */
}
set_error_handler('MailErrorHandler');
$undefined_var();
When the code above is run, I see in the browser window:
Errno=8 Errorstring=Undefined variable: undefined_var
Fatal error: Call to undefined function: () in d:\inetpub\wwwroot\php\err.php on line
14
In other words, the Fatal error is never caught by the error handler, and our
webmaster never detects that it is actually a very serious error, and not just an
undefined var E_NOTICE.
Thank you, John Lim
?
Edit this bug report at http://bugs.php.net/?id=14445edit=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]
[PHP-DEV] Bug #14446 Updated: is_file returns error
ID: 14446 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Filesystem function related Operating System: debian PHP Version: 4.1.0 New Comment: Thanks for your report. However, please do check the bug database for existing bug entries before submitting a new bug entry. This is a duplicate of #14424, #14420 and others Previous Comments: [2001-12-11 23:57:50] [EMAIL PROTECTED] is_file() and is_dir() functions return warning when filename supplied is not existing. The following warning is displayed: Warning: stat failed for temp.php (errno=2 - No such file or directory) Edit this bug report at http://bugs.php.net/?id=14446edit=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]
[PHP-DEV] Bug #14418 Updated: PHP and HTML FAQ should be improved
ID: 14418 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Documentation problem Operating System: PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: I should not fix it now, however, I don't want to forget about it. :) Previous Comments: [2001-12-11 03:26:49] [EMAIL PROTECTED] The PHP and HTML section of the FAQ needs to be improved. The information is incomplete and hard to understand. Edit this bug report at http://bugs.php.net/?id=14418edit=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]
[PHP-DEV] Bug #14304 Updated: Potential problem with regex...
ID: 14304
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Regexps related
Operating System: Linux php3-2 2.4.7 #1 Thu Aug 9
PHP Version: 4.0.6
New Comment:
I cannot reproduce the problem under PHP 4.1.0. Can you
upgrade to this version?
Previous Comments:
[2001-12-12 01:31:01] [EMAIL PROTECTED]
The problem is there...
I got the first result :
array(10) {
[0]=
string(24) phpdig:ignore_message/
[1]=
string(14) ignore_message
[2]=
...
But on the second, i got nothing but a 'maximum execution time exceeded'.
I traced my code with some echoes and flush(), and it seems that the php engine stays
on the eregi() function.
It not core dump, but Apache goes 100% CPU until the timeout occurs.
[2001-12-11 17:39:59] [EMAIL PROTECTED]
Thanks for the additional information.
I tested the code snippets provided on PHP 4.1.0 - they
all seem to operate as expected. The input of both
snippets (when fed to your original function) returns
'bri/i/td'
The regular expressions provided later seem to work as
well.
The top snippet captures:
array(10) {
[0]=
string(24) phpdig:ignore_message/
[1]=
string(14) ignore_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
...and the bottom snippet captures:
array(10) {
[0]=
string(31) phpdig:ignore_common_message/
[1]=
string(21) ignore_common_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
Is this the output that you get with PHP 4.0.6? Please let
me know!
[2001-12-09 08:08:18] [EMAIL PROTECTED]
Changed bug type to Regexps
[2001-12-09 08:00:37] [EMAIL PROTECTED]
I isolate the bug :
this works :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_message//i/td',$regs);
this doesn't (php loops) :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_common_message//i/td',$regs);
[2001-12-01 23:43:55] [EMAIL PROTECTED]
Please reduce this to a simpler test case. If there is a
bug in str_replace, then it should be reproduceable with a
simple one line test. Logging how the str_replace
functions are called should let you find the culprit.
A line like this after the function calls are made should
do the trick.
error_log ($line =
str_replace({$regs[0]},$replacement,$line);\n, 3,
'./str_rep_log');
Good Luck!
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14304
Edit this bug report at http://bugs.php.net/?id=14304edit=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] Problem with complex data structure and sessions
Probably the best thing to do is visit http://bugs.php.net and review the guidelines for submitting a bug. If you get through the process and feel that you have found a bug, please submit a bug report. --zak On December 10, 2001 02:51 pm, Frank wrote: I am new to online PHP communities so if there is a better place to post this please let me know. I may have encountered a bug in PHP 4.0.6, but I don't know where to look to see if it is a known problem, and I have not been able to reproduce the problem in trivial code. I have been programming for a couple decades now, but just started with PHP a few months ago. I've spent a couple months developing a fairly typical catalog / shopping cart / order system for a small web site. My code works flawlessly on 4.0.8 under Windows XP (my development environment), but when I uploaded it to our host (4.0.6 under FreeBSD) it failed in the following way: The Shopping cart (we call it a basket) object includes a two dimensional array of item objects indexed by catalog number and package size, and a second array of references to the same item objects. Simplified a little, items are added like this: $this-items[$catalognum][$size] = new BasketItem($catalognum, $size, $quantity); $this-ref[] = $this-items[$catalognum][$size]; Somewhere in the serialize/store/load/unserialize process handled by the built in session support, $basket-ref[] comes to contain references to arrays rather than references to objects. If I add an echo $basket-ref[0] line to a particular page it will print Object on the hit that creates the basket, and Array when I refresh the page. Under 4.0.8/Windows it will print Object each time. This problem causes my code to fail with a Call to a member function on a non-object error. Where can I best look to see if this is a known problem? -- 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] xmlrpc extension in 4.1.0
On December 10, 2001 03:42 pm, Colin Viebrock wrote: Any docs on using this extension? Hey Colin, There is an article on Zend - http://www.zend.com/zend/tut/tut-xml-rpc-client.php HTH, --zak -- 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]
