[PHP-DEV] Bug #12585: W3C service stops
From: [EMAIL PROTECTED] Operating system: NT 4.0 SP6a PHP version: 4.0.4pl1 PHP Bug Type: IIS related Bug description: W3C service stops I have a Webserver serving several sites. everything works fine for some time, but the the w3c service (WWW and FTP) stop working. there are no entries in the event log or elsewhere (at least I haven't found some) I can simply startup the www and ftp services again, everything is fine... I am using IIS 4 on NT 4.0 with SP6a and ODBC. This happens by using both, the *.dll and the *.exe version of php My workaround by now is restarting the webserver every 5 minutes -- Edit bug report at: http://bugs.php.net/?id=12585edit=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 #12563 Updated: Imlib2 Issue
ID: 12563 Updated by: wez Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: RedHat 7.1 / 2.4.7 Kernel PHP Version: 4.0.6 New Comment: imlib2 uses AC_ADD_LIBRARY and friends instead of PHP_ADD_LIBRARY and friends in it's config.m4; it is broken against CVS, but can be fixed easily. --Wez. Previous Comments: [2001-08-05 20:20:09] [EMAIL PROTECTED] The Imlib2 guys say it's a PHP bug: I reported what I thought to be a PHP bug, they say it's a bug in Imlib2. Please have a look. I don't see how this can be an imlib2 bug. it's a bug in php's autoconf/make etc. setup - probably related to how they do imlib2 detection and li checking. they should use imlib2-config [- 10:07AM ~ -]imlib2-config --version 1.0.4 [- 10:07AM ~ -]imlib2-config --cflags -I/usr/local/include -I/usr/X11R6/include [- 10:07AM ~ -]imlib2-config --libs -L/usr/local/lib -lImlib2 -lttf -lm -ldl -lXext -lXext -lX11 -L/usr/X11R6/lib [- 10:07AM ~ -]imlib2-config --prefix /usr/local [- 10:07AM ~ -]imlib2-config --help Usage: imlib2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs] [--cflags] to figure out cflags and link flags. this is likely a type.missing character or missing logic statement in their build procedure. it's not an imlib2 bug - unless your imlib2-config is spewing out empty results for --libs or --cflags... which it shoudln't. [2001-08-04 00:19:43] [EMAIL PROTECTED] Not a PHP bug. Report this to the imlib author instead. [2001-08-04 00:17:05] [EMAIL PROTECTED] make fails while trying to add Imlib2 support. ./configure --with-xml --with-apxs=/usr/sbin/apxs --with-mysql=/usr --with-pgsql --with-imlib I can see the configure script finds my new Imlib2 install: snip checking for imlib2 support... yes checking for imlib_load_image in -lImlib2... yes /snip anyway, here's the error: Making all in . make[1]: Entering directory `/usr/src/php-4.0.6' /bin/sh /usr/src/php-4.0.6/libtool --silent --mode=link gcc -I. -I/usr/src/php-4.0.6/ -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 -I/usr/include/apache -I/usr/src/php-4.0.6/Zend -I/usr/include/mysql -I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/src/php-4.0.6/TSRM -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -o libphp4.la -rpath /usr/src/php-4.0.6/libs -avoid-version -L/usr/local/pgsql/lib -R /usr/local/pgsql/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/imlib/libimlib.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/pgsql/libpgsql.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -ldl -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv /usr/bin/ld: cannot find -l--library=crypt collect2: ld returned 1 exit status make[1]: *** [libphp4.la] Error 1 make[1]: Leaving directory `/usr/src/php-4.0.6' make: *** [all-recursive] Error 1 I also tried adding a couple of paths to the --with-imlib switch, /usr/local/lib and /usr/local/include. Both variations produced the same error as above. I am trying to add imlib support. This is an upgrade on the same version of PHP I'm already running, 4.06. I experienced no missing crypt libraries on the previous install. I don't exactly understand why it's failing on this error: /usr/bin/ld: cannot find -l--library=crypt I don't see any kind of crypt files listed in the requirements for Imlib2: http://www.mcclanahan.cx/php_imlib/downloads.php If I leave off the --with-imlib option I get no errors, so I know that's the part that's breaking. When I installed Imlib2 there were no errors, and I see the files: locate Imlib2 /usr/local/lib/libImlib2.so.1.0.1 /usr/local/lib/libImlib2.so.1 /usr/local/lib/libImlib2.so /usr/local/lib/libImlib2.la /usr/local/lib/libImlib2.a /usr/local/include/Imlib2.h So I had a look at /etc/ld.so.conf. I added /usr/local/lib and ran ldconfig. This didn't help, same errors as above. A friend pointed out this: -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv ^ | Here's the problem I have no idea how to fix it, if this is the issue... I am using PHP 4.0.6 Apache 1.3.20 MySQL 3.23.40 Postgresql 7.1.2 Imlib2 1.0.1 RedHat 7.1 Edit this bug report at http://bugs.php.net/?id=12563edit=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,
Re: [PHP-DEV] PHP Extensions: C or C++?
On Mon, 6 Aug 2001, David Eriksson wrote: (One bug, I believe. But that's one too many of course.) Ooh..I remembered wrong then. I thought I had seen more..:) Or I'm thinking of something else. :) I do not maintain Satellite any more and Universe is indeed intended to replace Satellite. Cool. I never got Satellite to compile even.. --Jani -- 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] apache2filter XtOffsetOf' redefined
Hi, i can't compile the current cvs version with apache 2.0.18. make[3]: Entering directory `/home/schopohl/development/php4/sapi/apache2filter' /bin/sh /home/schopohl/development/php4/libtool --silent --mode=compile /home/schopohl/development/php4/meta_ccld -I. - I/home/schopohl/development/php4/sapi/apache2filter - I/home/schopohl/development/php4/main -I/home/schopohl/development/php4 -I/usr/local/apache/2.0.18/include - I/home/schopohl/development/php4/Zend - I/usr/local/mysql/current/include/mysql - I/home/schopohl/development/php4/ext/xml/expat -DNO_DBM_REWRITEMAP - D_REENTRANT -I../TSRM -I/home/schopohl/development/php4/TSRM -g -O2 - pthread -prefer-pic -c sapi_apache2.c In file included from /usr/local/apache/2.0.18/include/apr_buckets.h:61, from /usr/local/apache/2.0.18/include/util_filter.h:59, from sapi_apache2.c:33: /usr/local/apache/2.0.18/include/apr_general.h:115: warning: `XtOffsetOf' redefined /home/schopohl/development/php4/main/php.h:328: warning: this is the location of the previous definition sapi_apache2.c: In function `php_output_filter': sapi_apache2.c:330: too many arguments to function `ap_save_brigade' make[3]: *** [sapi_apache2.lo] Error 1 what's wrong? -- Holger -- 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] apache2filter XtOffsetOf' redefined
Holger Schopohl wrote: i can't compile the current cvs version with apache 2.0.18. Please upgrade to a recent Apache 2.0 version. It compiles fine with httpd-2.0's latest CVS. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- 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] CVS Account Request
Full name: Ozgur AKAN Email: [EMAIL PROTECTED] ID:ozgurakan Purpose: I am a member of php.org.tr and we want to translate the manual to Turskish. -- 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 #12563 Updated: Imlib2 Issue
ID: 12563 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Closed Bug Type: Compile Failure Operating System: RedHat 7.1 / 2.4.7 Kernel PHP Version: 4.0.6 New Comment: This indeed was the reason why it didn't work. The backwards compatibily fix for this AC_* - PHP_* conversion didn't really fix it. It is now fixed in CVS. Quick fix for imlib: change the AC_ADD_ to PHP_ADD_ in imlib/config.m4 and rerun buildconf. --Jani Previous Comments: [2001-08-06 03:52:22] [EMAIL PROTECTED] imlib2 uses AC_ADD_LIBRARY and friends instead of PHP_ADD_LIBRARY and friends in it's config.m4; it is broken against CVS, but can be fixed easily. --Wez. [2001-08-05 20:20:09] [EMAIL PROTECTED] The Imlib2 guys say it's a PHP bug: I reported what I thought to be a PHP bug, they say it's a bug in Imlib2. Please have a look. I don't see how this can be an imlib2 bug. it's a bug in php's autoconf/make etc. setup - probably related to how they do imlib2 detection and li checking. they should use imlib2-config [- 10:07AM ~ -]imlib2-config --version 1.0.4 [- 10:07AM ~ -]imlib2-config --cflags -I/usr/local/include -I/usr/X11R6/include [- 10:07AM ~ -]imlib2-config --libs -L/usr/local/lib -lImlib2 -lttf -lm -ldl -lXext -lXext -lX11 -L/usr/X11R6/lib [- 10:07AM ~ -]imlib2-config --prefix /usr/local [- 10:07AM ~ -]imlib2-config --help Usage: imlib2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs] [--cflags] to figure out cflags and link flags. this is likely a type.missing character or missing logic statement in their build procedure. it's not an imlib2 bug - unless your imlib2-config is spewing out empty results for --libs or --cflags... which it shoudln't. [2001-08-04 00:19:43] [EMAIL PROTECTED] Not a PHP bug. Report this to the imlib author instead. [2001-08-04 00:17:05] [EMAIL PROTECTED] make fails while trying to add Imlib2 support. ./configure --with-xml --with-apxs=/usr/sbin/apxs --with-mysql=/usr --with-pgsql --with-imlib I can see the configure script finds my new Imlib2 install: snip checking for imlib2 support... yes checking for imlib_load_image in -lImlib2... yes /snip anyway, here's the error: Making all in . make[1]: Entering directory `/usr/src/php-4.0.6' /bin/sh /usr/src/php-4.0.6/libtool --silent --mode=link gcc -I. -I/usr/src/php-4.0.6/ -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 -I/usr/include/apache -I/usr/src/php-4.0.6/Zend -I/usr/include/mysql -I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/src/php-4.0.6/TSRM -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -o libphp4.la -rpath /usr/src/php-4.0.6/libs -avoid-version -L/usr/local/pgsql/lib -R /usr/local/pgsql/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/imlib/libimlib.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/pgsql/libpgsql.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -ldl -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv /usr/bin/ld: cannot find -l--library=crypt collect2: ld returned 1 exit status make[1]: *** [libphp4.la] Error 1 make[1]: Leaving directory `/usr/src/php-4.0.6' make: *** [all-recursive] Error 1 I also tried adding a couple of paths to the --with-imlib switch, /usr/local/lib and /usr/local/include. Both variations produced the same error as above. I am trying to add imlib support. This is an upgrade on the same version of PHP I'm already running, 4.06. I experienced no missing crypt libraries on the previous install. I don't exactly understand why it's failing on this error: /usr/bin/ld: cannot find -l--library=crypt I don't see any kind of crypt files listed in the requirements for Imlib2: http://www.mcclanahan.cx/php_imlib/downloads.php If I leave off the --with-imlib option I get no errors, so I know that's the part that's breaking. When I installed Imlib2 there were no errors, and I see the files: locate Imlib2 /usr/local/lib/libImlib2.so.1.0.1 /usr/local/lib/libImlib2.so.1 /usr/local/lib/libImlib2.so /usr/local/lib/libImlib2.la /usr/local/lib/libImlib2.a /usr/local/include/Imlib2.h So I had a look at /etc/ld.so.conf. I added /usr/local/lib and ran ldconfig. This didn't help, same errors as above. A friend pointed out this: -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv ^ | Here's the problem I have no idea how to fix it, if this is the issue... I am using PHP
[PHP-DEV] Bug #12587: strange error_reporting(0)-behaviour
From: [EMAIL PROTECTED] Operating system: Linux (S.u.S.E 6.1) PHP version: 4.0.6 PHP Bug Type: PHP options/info functions Bug description: strange error_reporting(0)-behaviour hey buglist, no script necessary...;-) last friday i installed php4.0.6 (coming from php3.0.17) and found out that it isn't possible any longer to suppress a forgotten ';' parse error by setting up error_reporting(0) in my scripts...*sigh* but if i code a error_reporting = 0 into the php.ini, those error (forgotten ';') is suppressed and cannot be shown again by setting error_reporting(E_ALL) in my script...;-( is that the intented aim?! i known about the many, many error-levels and there possibilities, but it would be nice to have the chance to suppress or not those trivial errors in my scripts as well, if desired. bye, daniel -- Edit bug report at: http://bugs.php.net/?id=12587edit=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 #12588: PHP engine hangs
From: [EMAIL PROTECTED] Operating system: NT4.0 SP5 PHP version: 4.0.6 PHP Bug Type: Reproducible crash Bug description: PHP engine hangs I downloaded PHP 4.0.6 binary for win32. I installed it on IIS4 (which was perfectly working in ASP and PERL mode), as a CGI module or A ISAPI filter, and in both cases , it crashes IIS completely after few requests (I need to start again the www service). I also tried to install this version of PHP as a module for Apache-win32 1.3.20 , and the PHP engine crashed after few requests too.. I 've no error codes in my logs, nothing appears to be wrong in my php.ini The db engine used is an access database connected via odbc to the web site... please Help, It's going to make me mad :-( -- Edit bug report at: http://bugs.php.net/?id=12588edit=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 #12589: juliantojd () returns incorrect JD
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.0.5 PHP Bug Type: Calendar related Bug description: juliantojd () returns incorrect JD juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001) returns 2452134 instead of 2452121. See http://www.aavso.org/cdata/jdcalendar.stm (But jddayofweek() works well with the proper JD!) -- Edit bug report at: http://bugs.php.net/?id=12589edit=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 #12589 Updated: juliantojd () returns incorrect JD
ID: 12589 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Calendar related Operating System: Win2K PHP Version: 4.0.5 New Comment: I was confused with the julian and gregorian calendars... Previous Comments: [2001-08-06 07:22:48] [EMAIL PROTECTED] juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001) returns 2452134 instead of 2452121. See http://www.aavso.org/cdata/jdcalendar.stm (But jddayofweek() works well with the proper JD!) Edit this bug report at http://bugs.php.net/?id=12589edit=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 #12589 Updated: juliantojd () returns incorrect JD
ID: 12589 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Duplicate Status: Bogus Bug Type: Calendar related Operating System: Win2K PHP Version: 4.0.5 New Comment: user error. :) Previous Comments: [2001-08-06 07:28:07] [EMAIL PROTECTED] I was confused with the julian and gregorian calendars... [2001-08-06 07:22:48] [EMAIL PROTECTED] juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001) returns 2452134 instead of 2452121. See http://www.aavso.org/cdata/jdcalendar.stm (But jddayofweek() works well with the proper JD!) Edit this bug report at http://bugs.php.net/?id=12589edit=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 #12498 Updated: cant config magic_quotes_off
ID: 12498 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: *Configuration Issues Operating System: Windows 4.9 (Me) PHP Version: 4.0.6 New Comment: Are you running PHP in CGI mode? Or as apache module? And have you read the install.txt file? It says where you should put php.ini in your system. --Jani Previous Comments: [2001-07-31 22:35:36] [EMAIL PROTECTED] Hi I have installed 4.0.6 and have had no major problems it seems however That I can't change the config from the compiled in data, i.e. I have installed Ariadne, and it requires magic_guotes_gpc to be 'off' so I modified the php.ini in the windows dir to set magic_quotes_gpc to be off but then php crashes, and wont recognise any php script, as in 'Warning: Failed opening '/apache/htdocs/phpinfo.php' for inclusion (include_path='.;c:\apache\php\includes;c:\apache\includes;c:\apache\htdocs') in Unknown on line 0' any help would be appreciated as I need to run Ariadne locally during development. n.b. if I remove php.ini from the windows dir, phpinfo.php runs (as does everything else Php wise) and phpinfo states that the php.ini file is in c:\winnt which of course it isn't??? Sincerely yours George R Wood. Edit this bug report at http://bugs.php.net/?id=12498edit=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 #12590: hex const (0xABCDEF01) parsing error
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: Scripting Engine problem Bug description: hex const (0xABCDEF01) parsing error Looks like there's some trouble with parsing big hex consts (those with sign bit set). Try this: ... echo (0x7FFF00FF 0x); //echoes 255 echo (0x80FF 0x); //echoes 0!!! ... 0x80FF apparently is mis-parsed. -- Edit bug report at: http://bugs.php.net/?id=12590edit=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 #12502 Updated: oci8.dll can't be loaded
ID: 12502 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: OCI8 related Operating System: WinNT and Windows 2000 PHP Version: 4.0.6 New Comment: Ask support questions on the appropriate mailing list: http://www.php.net/support.php ( php-db / php-windows ) after you have searched the archives, of course. --Jani Previous Comments: [2001-08-02 11:57:23] [EMAIL PROTECTED] sorry ORACLE VERSION 8.05 [2001-08-02 11:56:00] [EMAIL PROTECTED] I found in the faqs the following (exactly the same problem) This problem was also seen under the ODBC drivers for Windows. The solution so far has been to remove all Windows based carriage returns (\r\n) in your TNSNames.ora and SQLNet.ora file, and replace them with unix style carriage returns (\n). This should end your problem. Why is this happening? It's unknown at the time, but is being investigated. I convert this 2 files to Unix format (only \n) but the problem still happend. any help? [2001-08-01 21:54:15] [EMAIL PROTECTED] Sniper, I change my php.ini I comment php_oci8.dll and uncomment php_oracle.dll This work. But now I recieve the following problem: TNS:could not resolve service name I try with $db= ora_logon(demo_user/demo_password@demo,); This TNS exist and the user and the password too. (this is the right place for this question?) thank you again. [2001-08-01 15:58:57] [EMAIL PROTECTED] I don't understand this program. Please check this image : http://www.netred.cl/php.jpg (image of my screen). [2001-08-01 10:20:42] [EMAIL PROTECTED] to look on which external dlls an exe or an dll is relying you can use the dependency walker - http://www.dependencywalker.com/ 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=12502 Edit this bug report at http://bugs.php.net/?id=12502edit=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 #12591: php -l doesn't output anything
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.0.6 PHP Bug Type: PHP options/info functions Bug description: php -l doesn't output anything under windows, in the php.exe directory : php -l php.exe, no output, no complain, you can try with whatever you want, either good or bad php, binary or text file. PHP.net windows zip. -- Edit bug report at: http://bugs.php.net/?id=12591edit=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 #12591 Updated: php -l doesn't output anything
ID: 12591 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: PHP options/info functions Operating System: Windows 98 PHP Version: 4.0.6 New Comment: This should be fixed in CVS. Try a snapshot: http://www.zend.com/snapshots/ --Jani Previous Comments: [2001-08-06 07:39:20] [EMAIL PROTECTED] under windows, in the php.exe directory : php -l php.exe, no output, no complain, you can try with whatever you want, either good or bad php, binary or text file. PHP.net windows zip. Edit this bug report at http://bugs.php.net/?id=12591edit=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 #12555 Updated: imap_body on empty messages causes seg fault
ID: 12555 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: IMAP related Operating System: Linux PHP Version: 4.0.6 New Comment: I can not reproduce this with PHP 4.0.6. With which c-client version is your PHP linked with? --Jani Previous Comments: [2001-08-03 12:08:10] [EMAIL PROTECTED] After opening an imap connection, calling imap_body for a message which is has an empty body will cause the apache server to seg fault (11). This caused several problems as on some of our accounts the first message was empty (for other reasons) and so any php imap client would fail immediately on loading. We have fixed this by testing for message size - but the imap_body code should probably spot this. Thanks, Jon. Edit this bug report at http://bugs.php.net/?id=12555edit=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] apache2filter XtOffsetOf' redefined
In article [EMAIL PROTECTED], sb@sebastian- bergmann.de says... Holger Schopohl wrote: i can't compile the current cvs version with apache 2.0.18. Please upgrade to a recent Apache 2.0 version. It compiles fine with httpd-2.0's latest CVS. okay, that works fine, thanks. someone has wrote in sapi/apache2filter/README, that i must only write Files *.php SetOutputFilter PHP SetInputFilter PHP /Files is it all? no AddType ? my apache parse no .php file... -- Holger -- 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] apache2filter XtOffsetOf' redefined
Holger Schopohl wrote: Files *.php SetOutputFilter PHP SetInputFilter PHP /Files is it all? no AddType ? This is correct. PHP registers itself as a filter with Apache 2. my apache parse no .php file... It works. At least on my and Sascha's machines :-) -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- 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] RES: Bug #12471 Updated: DCOM don't running
Hi, I'm brasilian this is o code i'm try running!! html head titleTeste PHP COM/title /head body pTeste PHP COM/DCOM/p ? /* CP_ACP - ANSI code page CP_MACCP - Macintosh code page CP_OEMCP - OEM code page CP_SYMBOL - Windows 2000: Symbol code page (42) CP_THREAD_ACP - Windows 2000: Current thread's ANSI code page CP_UTF7 - Windows NT 4.0 and Windows 2000: Translate using UTF-7 CP_UTF8 - Windows NT 4.0 and Windows 2000: Translate using UTF-8. When this is set, \ dwFlags must be zero. */ $conv = new COM(APS_servidor.APS_geral,detweb, CP_ACP) or die(Objeto COM não instânciado!); $text = $conv-Escreve_texto(Terrible); echo $text; ? /body /html This too is my php.ini!!! [Sockets] sockets.use_system_read=On ; Use the system read() function instead of ; the php_read() wrapper. ; Local Variables: ; tab-width: 4 ; End: ;com.typelib_file = com.allow_dcom = on -- 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 #12536 Updated: fread does not look to be working right
4.0.6 is stable get it at http://php.net/downloads.php On Sun, 05 Aug 2001, knight wrote: I have not tried it with the 4.0.6 php, is that a stable version yet??? Can I use the ms 6.0 compiler to compile php? Does it matter what compiler I use?? What compiler do you recommend? I will update the message with a example Brendan Ferguson -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: August 2, 2001 5:38 PM To: [EMAIL PROTECTED] Subject: Bug #12536 Updated: fread does not look to be working right ID: 12536 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Performance problem Operating System: win 98 box PHP Version: 4.0.4pl1 New Comment: Have you tried with PHP 4.0.6? And could you also add a short example script into this bug report? --Jani Previous Comments: [2001-08-02 17:34:06] [EMAIL PROTECTED] fread does not look like it is reading the EOF. when i use a large (HUDGE) number to tell the fread() how many characters to read, it takes a l o n g time for this to complete this happens even when the file is very short. i descoverd this when i was trying to read an entire file into a string. is fread the best way to do this?? it does not seem to be working very well. there is also a error reporting problem with fread. after the same number gets too big, php stops processing the entire page, (it does check syntax) there is als no error message when this happens. Knight ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=12536edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12349 Updated: Broken PNG image
ID: 12349 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: GD related Operating System: Windows 98 PHP Version: 4.0.6 New Comment: This is a bug in the GD-2.0.1 (beta) library. Closed. --Jani Previous Comments: [2001-07-25 03:47:46] [EMAIL PROTECTED] I use standart version of PHP, downloaded from www.php.net i think in PHP 4.0.5 and 4.0.6 used GD 1.8.4 but in PHP 4.0.6 ChangeLog file i see some GD 2.0.1 function [2001-07-24 21:45:02] [EMAIL PROTECTED] Which version of GD do you have? [2001-07-24 21:43:36] [EMAIL PROTECTED] No, only with PNG, with JPG format working fine, and i dont install GIF support, only standart installation of PHP 4.0.6 And - i copy php_gd.dll from PHP 4.0.5 in to PHP 4.0.6 directory - CopyResized working, but some GD function not working - PHP crashed. PS Sorry for bad english, im living in Ukraine and dont have big language practic [2001-07-24 17:39:23] [EMAIL PROTECTED] does this happen with jpgs or gifs (if you have support for gifs)? [2001-07-24 14:33:30] [EMAIL PROTECTED] i have problem with create small copy of PNG transparent images: Windows 98 apache 1.3.20 php 4.0.6 ? Header(Content-type: image/png); $s = GetImageSize($rimg); if ($s[0]$s[1]) $z = $s[0]/60; else $z = $s[1]/60; $x = (int)($s[0]/$z); $y = (int)($s[1]/$z); $dst_img = ImageCreate($x,$y); $src_img = ImageCreateFromPNG(../img/test.png); $colT = ImageColorAllocate($dst_img,0,255,0); ImageFill($dst_img,0,0,$colT); ImageCopyResized($dst_img,$src_img,0,0,0,0,$x,$y,$s[0],$s[1]); ImageColorTransparent($dst_img,$colT); ImagePNG($dst_img); ImageDestroy($src_img); ImageDestroy($dst_img); ? and i have broken fullcolored rectangle BUT - with php 4.0.5 work all best Edit this bug report at http://bugs.php.net/?id=12349edit=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 #12581 Updated: boolean fields not imported (patches enclosed)
I didn't think that opening a bug report just to
put a patch in it was correct. Patches are
supposed to be sent to the php-dev mailing list.
Was I wrong?
On Sun, 05 Aug 2001, Jani Taskinen wrote:
Could you please tell me what is the 'Bogus' in this report?
It's a bug report which happens to have a patch for the bug too.
This is far from bogus report. Reopened.
--Jani
On 5 Aug 2001 [EMAIL PROTECTED] wrote:
ID: 12581
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: dBase related
Operating System: Linux 2.2.16-3
PHP Version: 4.0.6
New Comment:
status - bogus
Previous Comments:
[2001-08-05 16:18:03] [EMAIL PROTECTED]
this is not a bug...already forwarded to [EMAIL PROTECTED]
Thanks for your help, but next time just send it to [EMAIL PROTECTED]
and don't open a bug about it.
[2001-08-05 16:17:47] [EMAIL PROTECTED]
The file name to which the patches apply is ext/dbase/dbase.c.
[2001-08-05 16:16:32] [EMAIL PROTECTED]
Below are patches that fix the problem reported 10/20/2000 in bug report #7374.
The problem is that when boolean (TRUE or FALSE) fields are present in an imported
Dbase file, the value is always imported as FALSE (0). This problem has been present
since 4.0.3. The patches below were generated using distribution 4.0.6.
466,467c466
case 'N': /* FALLS THROUGH */
case 'L': /* FALLS THROUGH */
---
case 'N':
473a473,486
case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
and insert 1 or 0, respectively. db_fdc is the number of
decimals, which we don't care about. 3/14/01 LEW */
if ( (*str_value == 'T') || ( *str_value == 'Y' ) ){
add_next_index_long(return_value, strtol(1, NULL, 10));
} else {
if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
add_next_index_long(return_value, strtol(0, NULL, 10));
}
else {
add_next_index_long(return_value, strtol( , NULL, 10));
}
}
break;
544,545c557
case 'N': /* FALLS THROUGH */
case 'L': /* FALLS THROUGH */
---
case 'N':
551a564,578
case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
and insert 1 or 0, respectively. db_fdc is the number of
decimals, which we don't care about. 3/14/01 LEW */
if ( (*str_value == 'T') || ( *str_value == 'Y') ){
add_assoc_long(return_value, cur_f-db_fname, strtol(1,
NULL, 10));
} else {
if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
add_assoc_long(return_value, cur_f-db_fname,strtol(0,
NULL, 10));
}
else {
add_assoc_long(return_value, cur_f-db_fname,strtol( ,
NULL, 10));
}
}
break;
Edit this bug report at http://bugs.php.net/?id=12581edit=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 #12555 Updated: imap_body on empty messages causes seg fault
ID: 12555 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 4.0.6 New Comment: The version linked to from the documentation pages (4.7 i believe) - though I have tried others (regressing back). I am minded that this 'could' be a very isolated error caused by the imap mailbox containing 0 byte files (which clearly would not happen very often). If this is the case, contact me for details of how to access an account with these 0byte files. Thanks, Previous Comments: [2001-08-06 07:51:14] [EMAIL PROTECTED] I can not reproduce this with PHP 4.0.6. With which c-client version is your PHP linked with? --Jani [2001-08-03 12:08:10] [EMAIL PROTECTED] After opening an imap connection, calling imap_body for a message which is has an empty body will cause the apache server to seg fault (11). This caused several problems as on some of our accounts the first message was empty (for other reasons) and so any php imap client would fail immediately on loading. We have fixed this by testing for message size - but the imap_body code should probably spot this. Thanks, Jon. Edit this bug report at http://bugs.php.net/?id=12555edit=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 #12593: Serious Ouput Problem in input tag
From: [EMAIL PROTECTED]
Operating system: Window 2000 server with IIS
PHP version: 4.0.6
PHP Bug Type: Session related
Bug description: Serious Ouput Problem in input tag
The session_register() seems accessing wrong memory address and causing
some strange bugs.
The following phtml shows the bugs. Please run it and see the ouput of the
source code from Internet Explorer.
--
--
?
if (isset($PHPSESSID)) {
session_id($PHPSESSID);
}
session_register(strSessionLoginName,strSessionLoginId);
if (empty($strSessionLoginName)) {
session_destroy();
}
?
HTML
BODY
FORM name='form_quest' method=post action=''
TABLE border=0 cellspacing=0 align=center width=100%
TR class='styTRQuestion10'
TD class='styTDQuestion1' width='94%'
? echo It is a serious bug. ?
/TD
/TR
TRTD class='styTDAnswer10'TABLE
TRTD class='styTDAnswer10'INPUT type=radio
name='f2_0' value=1-0
onchange='' onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'apple/TD
TDINPUT type=radio name='f2_0' value='2-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'banana/TD
TDINPUT type=radio name='f2_0' value='4-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'pear/TD/TR
TRTDINPUT type=radio name='f2_0' value='8-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'orange/TD
TDINPUT type=radio name='f2_0' value='16-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'water-melon/TD
TDINPUT type=radio name='f2_0' value='32-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'sweet-melon/TD/TR
/TABLE
/TD/TR
/TABLE
/FORM
/BODY
/HTML
---
---
Here is the source output from internet explorer:
HTML
BODY
FORM name='form_quest' method=post action=''input type=hidden
name=PHPSESSID value=5bc972fec5e1fc9f0166035c7f189f9e /
TABLE border=0 cellspacing=0 align=center width=100%
TR class='styTRQuestion10'
TD class='styTDQuestion1' width='94%'
It is a serious bug./TD
/TR
TRTD class='styTDAnswer10'TABLE
TRTD class='styTDAnswer10'INPUT type=radio
name='f2_0'
value=1-0 onchange='' onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'apple/TD
TDINPUT type=radio name='f2_0' value='2-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'banana/TD
TDINPUT type=radio name='f2_0' value='4-0'
_ I ? ? /TD
onchange='' onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'pear/TD/TR
TRTDINPUT type=radio name='f2_0' value='8-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'orange/TD
TDINPUT type=radio name='f2_0' value='16-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'water-melon/TD
TDINPUT type=radio name='f2_0' value='32-0' onchange=''
onKeyPress='return fncNoEnt(event)'/TDTD
style='padding-right:6px'sweet-melon/TD/TR
/TABLE
/TD/TR
/TABLE
/FORM
/BODY
/HTML
--
Edit bug report at: http://bugs.php.net/?id=12593edit=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 #9639 Updated: Nasty bug in mod_mm.c causes CGI POST to stop working
ID: 9639
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: Red Hat
PHP Version: 4.0.4pl1
New Comment:
Please create this patch against the latest CVS.
And put it somewhere in the net to be downloaded and
add the url here.
--Jani
Previous Comments:
[2001-06-27 11:31:29] [EMAIL PROTECTED]
Does this happen with 4.0.6 (now that is released) ?
--Jani
[2001-06-14 23:27:47] [EMAIL PROTECTED]
Does this still happen with PHP 4.0.6RC3:
http://www.php.net/~andi/php-4.0.6RC3.tar.gz
If above link does not work, change RC3 to RC4.
--Jani
[2001-03-08 17:10:21] [EMAIL PROTECTED]
On RedHat 6.2 or 7 machine with more than 67M of shared memory available
per process (this number is stored in /proc/sys/kernel/shmmax)
Compile Apache with ssl modules.
Compile mod_php into Apache --with-mm
Have 3300 ( or anything less than 67M) in /proc/sys/kernel/shmmax on
machine where you're running Apache - CGI POST stops working, stdin is
empty. This happens regardless of what kind of cgi script is executted
by the form, it doesn't have to be a php script. Increase the number in
/proc/sys/kernel/shmmax to something more than 67M, everything works
again. This 67M number is hardcoded in mm_create from mm library by
their configure script, which checks how much memory is available.
I have no explanation for it, because all mod_mm does in this case is
returning FAILURE if there is not enough memory. Go figure...
Here is my proposal: lets check how much memory is there before calling
mm_create in mod_mm.c by doing this: (I put the actual patch at the
bottom)
Add two new functions ( pretty much copied from mm configure)
static int test_mem_size (unsigned long size)
{
int fd;
void *segment;
#ifdef MM_SHMT_MMFILE
char file[] = ./ac_test.tmp;
unlink(file);
if ((fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)
return 0;
if (ftruncate(fd, size) == -1)
return 0;
if ((segment = (void *)mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, fd, 0)) == MAP_FAILED) {
close(fd);
return 0;
}
munmap((caddr_t)segment, size);
close(fd);
unlink(file);
#endif
#ifdef MM_SHMT_IPCSHM
if ((fd = shmget(IPC_PRIVATE, size, SHM_R|SHM_W|IPC_CREAT)) == -1)
return 0;
if ((segment = (void *)shmat(fd, NULL, 0)) == ((void *)-1)) {
shmctl(fd, IPC_RMID, NULL);
return 0;
}
shmdt(segment);
shmctl(fd, IPC_RMID, NULL);
#endif
return 1;
}
#define ABS(n) ((n) = 0 ? (n) : (-(n)))
static unsigned long get_max_mem_size()
{
unsigned long t, m, b;
int d;
int rc;
/*
* Find maximum possible allocation size by performing a
* binary search starting with a search space between 0 and
* 64MB of memory.
*/
t = 1024*1024*64 /* = 67108864 */;
if (test_mem_size(t))
m = t;
else {
m = 1024*1024*32;
b = 0;
for (;;) {
/* fprintf(stderr, t=%d, m=%d, b=%d\n, t, m, b); */
rc = test_mem_size(m);
if (rc) {
d = ((t-m)/2);
b = m;
}
else {
d = -((m-b)/2);
t = m;
}
if (ABS(d) 1024*1) {
if (!rc)
m = b;
break;
}
if (m 1024*8)
break;
m += d;
}
if (m 1024*8)
m = 0;
}
return m;
}
The actual patch would look like this:
--- ext/session/mod_mm.c Fri Nov 3 07:00:49 2000
+++ ext/session/mod_mm.c Tue Feb 27 14:09:31 2001
@@ -173,9 +173,84 @@
#define PS_MM_DATA ps_mm *data = PS_GET_MOD_DATA()
+static int test_mem_size (unsigned long size)
+{
+int fd;
+void *segment;
+#ifdef MM_SHMT_MMFILE
+char file[] = ./ac_test.tmp;
+unlink(file);
+if ((fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)
+return 0;
+if (ftruncate(fd, size) == -1)
+return 0;
+if ((segment = (void *)mmap(NULL, size, PROT_READ|PROT_WRITE,
+MAP_SHARED, fd, 0)) == MAP_FAILED) {
+close(fd);
+return 0;
+}
+munmap((caddr_t)segment, size);
+close(fd);
+unlink(file);
+#endif
+#ifdef MM_SHMT_IPCSHM
+if ((fd = shmget(IPC_PRIVATE, size, SHM_R|SHM_W|IPC_CREAT)) == -1)
+return 0;
+if ((segment = (void *)shmat(fd, NULL, 0)) == ((void *)-1)) {
+shmctl(fd, IPC_RMID, NULL);
+return 0;
+}
+shmdt(segment);
+shmctl(fd, IPC_RMID, NULL);
+#endif
+
[PHP-DEV] Bug #10833 Updated: Hyperlink tag a when split on multiple lines, session ids are not propagated
ID: 10833 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.0.5 New Comment: No feedback. And the latest CVS works just fine on this kind of urls. --Jani Previous Comments: [2001-07-10 05:05:45] [EMAIL PROTECTED] Could you give a snapshot a try? http://snaps.php.net/ The scanner is supposed to ignore whitespace. [2001-05-12 17:24:31] [EMAIL PROTECTED] This applicable for browsers that don't allow cookies: The following is not working: a class=subMenu href=?php if (!isset($currentMenu)) echo $smUrlRefs[$key]; else echo ../ . $smUrlRefs[$key]; ? Menu /a But if href is on the same line as a tag, it works: a class=subMenu href=?php if (!isset($currentMenu)) echo $smUrlRefs[$key]; else echo ../ . $smUrlRefs[$key]; ? Menu /a Edit this bug report at http://bugs.php.net/?id=10833edit=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 #12594: Unable to load dynamic library
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.6 PHP Bug Type: Dynamic loading Bug description: Unable to load dynamic library I'm recieve the following error: Unable to load dynamic library for the extensions: libmcrypt.dll php_mssql.dll Some other extensions work fine. php_mssql.dll is included with php 4.0.6 and libmcrypt is downloaded from a link at php.net so help me out please, Regards Huib -- Edit bug report at: http://bugs.php.net/?id=12594edit=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 #12595: $argv passing
From: [EMAIL PROTECTED] Operating system: win2k (prob. all win\'s) PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: $argv passing When installing php on win32 it creates a registry record at My Computer\HKEY_CLASSES_ROOT\Applications\ named php.exe the problem is that the value of My Computer\HKEY_CLASSES_ROOT\Applications\php.exe\shell\open\command\ is default 'C:\php\php.exe %1' it means it only passes to php.exe the first argument = the name of the file and it do NOT pass any other arguments. The solution is (maybe can be in a newer version of win32 php) to set the value to 'C:\php\php.exe -q %1 %2 %3 %4 %5 %6 %7 %8 %9' (maybe without the -q argument) Sorgo -- Edit bug report at: http://bugs.php.net/?id=12595edit=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 #10895 Updated: Segmentation Fault
ID: 10895 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: Sun Solaris 5.8 on Intel PHP Version: 4.0.5 New Comment: no feedback Previous Comments: [2001-06-14 23:42:56] [EMAIL PROTECTED] We need a GDB backtrace of the crash, otherwise it is impossible to know what causes it. First get the latest RC from here: http://www.php.net/~andi/php-4.0.6RC3.tar.gz If above link doesn't work, try with RC4. Then configure it using same options as before but change the --disable-debug to --enable-debug otherwise the result of GDB is useless. [2001-05-16 04:02:52] [EMAIL PROTECTED] I had got Segmentation Faults using the sessions with PHP 4.05. After installing PHP 4.04pl1 the same code works fine. I use the session_start(),session_register(),session_unregister() functions. But i could not localize which of them causes the problems, i'd expect that it is session_unregister(). ./configure \ --with-mysql=/usr/local/mysql \ --with-apache=../apache_1.3.19 \ --enable-dbg=shared \ --with-ttf=/usr/local \ --with-gd \ --with-xml \ --with-zlib=/usr/local \ --with-jpeg-dir=/usr/local \ --enable-track-vars \ --enable-url-includes \ --disable-debug \ Claus Edit this bug report at http://bugs.php.net/?id=10895edit=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 #10955 Updated: session configured with session_set_save_handler and a database
ID: 10955 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: Red Hat Linux release 6.2 (Zoot) PHP Version: 4.0.5 New Comment: no feedback Previous Comments: [2001-06-12 16:23:32] [EMAIL PROTECTED] any chance you can try one of the latest RCs for 4.0.6? There was an update for the set_save function done recently I believe. [2001-05-18 11:08:06] [EMAIL PROTECTED] The problem is that when i'm using session_set_save_handler to store session data on an oracle base with php4.0.5, the 'write' function is never called, whereas on a 4.0.4pl1 it works fine ! The 4.0.4pl1 PHP (the good one) is running on a 2000 system, with the same php.ini as below php4.0.5 (the bad one ?) was installed on a linux like this: Configure Command: './configure' '--with-oci8' '--with-apache=../apache_1.3.19' '--enable-track-vars' with this php.ini: [PHP] ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; bitwise AND ; ~ bitwise NOT ; ! boolean NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none ; sets foo to an empty string ; foo = none; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a dynamically ; loaded extension (either a PHP extension or a Zend extension), you may only ; use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision = 14 ; number of significant digits displayed in floating point numbers y2k_compliance = Off ; whether to be year 2000 compliant (will cause problems with non y2k compliant browsers) output_buffering= Off ; Output buffering allows you to send header lines (including cookies) ; even after you send body content, in the price of slowing PHP's ; output layer a bit. ; You can enable output buffering by in runtime by calling the output ; buffering functions, or enable output buffering for all files ; by setting this directive to On. output_handler = ; You can redirect all of the output of your scripts to a function, ; that can be responsible to process or log it. For example, ; if you set the output_handler to ob_gzhandler, than output
[PHP-DEV] Bug #11573 Updated: Malformed HTTP response Header
ID: 11573 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.0.5 New Comment: no feedback Previous Comments: [2001-06-20 12:04:09] [EMAIL PROTECTED] Which broswser and what version of it? Please include a short but complete not working script into this report. --Jani [2001-06-20 05:04:48] [EMAIL PROTECTED] I'm using the session*() functions and test them with a browser which refuses cookies. So I add PHPSESSID=. as a parameter of the requested url. For example, I call qcmcreate.php?parm1=xxxparm2=yyyPHPSESSID=z. I noticed that the HTTP header returned by my script contain an extra line that confuses my client. The end of the HTTP header looks like: Content-Type: test/html \r\n \r\n xxx \r\n \r\n (\r\n means a blank and empty line) What's wrong here are the xxx\r\n\r\n lines. Where xxx is up to 3 characters. These 3 lines make my client misinterpret the server response. If I make my browser accept cookies, the problem disappears. To make sure I did not echo anything, the 1st instruction of my qcmcreate.php script is die; What's wrong ? Thank you, Jerome Pl Edit this bug report at http://bugs.php.net/?id=11573edit=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 #11883 Updated: unmotivated memory exhausting
ID: 11883 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: Linux Kernel 2.2.16 PHP Version: 4.0.6 New Comment: no feedback Previous Comments: [2001-07-04 14:30:24] [EMAIL PROTECTED] Please try the patch found at: http://www.php.net/do_download.php?download_file=php-4.0.6-memlimit.diff.gzsource_site=www.php.net [2001-07-04 13:47:36] [EMAIL PROTECTED] using apache with php-module v4.0.6, mysql3.23.35; configure: './configure' '--with-apxs=/virtual/development/httpd/bin/apxs' '--without-debug' '--with-config-file-path=/virtual/development/httpd/conf' '--enable-sysvsem' '--enable-sysvshm' '--enable-shmop' '--with-ftp' '--enable-track-vars=yes' '--enable-gd-native-ttf' '--enable-memory-limit=yes' '--enable-magic-quotes=yes' '--enable-trans-sid=yes' '--enable-inline-optimization' '--with-mysql=/usr/local/mysql' '--with-ttf=/usr/lib/freetype2' '--with-zlib' '--enable-calendar' '--with-jpeg-dir=/usr/local/lib' '--with-pnglib=/usr/local/lib' '--with-gd' '--enable-sockets' we had no problems at all with 4.0.5, but since we have 4.0.6 on our server, we get unmotivated memory exhausting at any script on any line. the error does not occure regularly, but when it happens, it comes many times in a row, just like php needs a bit of time to eat the memory, then crashes multiple times, and finally finds peace for a few hours working correctly. till the next day or so. I can't give you a code-snippet to reproduce it, because when the error occurs, you can simply reload the page and most of the times it then works, but only most of the times... Edit this bug report at http://bugs.php.net/?id=11883edit=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 #11914 Updated: Segmentation fault on Apache 1.3.20/1.3.19
ID: 11914 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Apache related Operating System: SuSE 7.0 PHP Version: 4.0.6 New Comment: no feedback Previous Comments: [2001-07-06 03:28:38] [EMAIL PROTECTED] What is your configure line? (To both Apache and PHP) Derick [2001-07-05 15:50:29] [EMAIL PROTECTED] I was installing PHP support on my Apache 1.3.19 as Static Module, when after I done the steps for installing and starting Apache daemon I was the following error messages on apache's log: [Thu Jul 5 15:44:43 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 configured -- resuming normal operations [Thu Jul 5 15:45:31 2001] [notice] child pid 24328 exit signal Segmentation fault (11) [Thu Jul 5 15:45:34 2001] [notice] child pid 24327 exit signal Segmentation fault (11) And all requests I did to my webserver I received that messages and nothing was returned back to my browser After some tries to compile with different apache versions, I tried to compile a different PHP version, 3.0.5, with my Apache on Static Mode, and I got it! I don't know what is going on with PHP/4.0.6, but I couldn't install with Apache/1.3.20 on a SuSE 7.0 p.s. - I tried once a installation as Dynamic Module and I hadn't sucessful too. p.s. 2 - I used the following parameters to configure PHP, other parameters were default: ./configure --with-pgsql=/usr/lib/pgsql/ --with-apache=../apache_1.3.20 --enable-track-vars [2001-07-05 15:38:30] [EMAIL PROTECTED] I was installing PHP support on my Apache 1.3.19 as Static Module, when after I done the steps for installing and starting Apache daemon I was the following error messages on apache's log: [Thu Jul 5 15:44:43 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 configured -- resuming normal operations [Thu Jul 5 15:45:31 2001] [notice] child pid 24328 exit signal Segmentation fault (11) [Thu Jul 5 15:45:34 2001] [notice] child pid 24327 exit signal Segmentation fault (11) And all requests I did to my webserver I received that messages and nothing was returned back to my browser After some tries to compile with different apache versions, I tried to compile a different PHP version, 3.0.5, with my Apache on Static Mode, and I got it! I don't know what is going on with PHP/4.0.6, but I couldn't install with Apache/1.3.20 on a SuSE 7.0 p.s. I tried once a installation as Dynamic Module and I hadn't sucessful too. Edit this bug report at http://bugs.php.net/?id=11914edit=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 #11951 Updated: HTML encoding problem
ID: 11951 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.0.5 New Comment: no feedback Previous Comments: [2001-07-07 19:52:59] [EMAIL PROTECTED] Have you checked the default_charset in your php.ini? [2001-07-07 18:18:16] [EMAIL PROTECTED] There definately seems to be a problem using any operating system I've tried (Linux Debian, RedHat, Windows 98, Windows 2000). The problem is that the following piece of HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type CONTENT=text/html; charset=windows-1251 ... will somehow be ignored, i.e. the document will not have this encoding set, instead ISO-8859-1 will be used. The biggest problem is that if try to change the encoding in the browser it won't change it, even though the browser will show it changed or if it changes it (very rare), after you reload the page the encoding is set back to ISO-8859-1, even though the browser always shows that the encoding is changed. This happens for all files that are processed by the php engine. I've correctly set the encoding option in the php.ini, even though it is always best for php, not to set this at all, since if you're using a remote server, for example hosting you site in the USA, but the page is in cyrillic, your php pages will never display properly. Probably the best thing is to leave the encoding up to the HTML headers set by each page. My workaround for this problem is (it always works correctly): ? include set_encoding.inc; ? !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head meta http-equiv=Content-Type CONTENT=text/html; charset=windows-1251 where set_encoding.inc, contains in my case the following: header(Content-type: text/html;charset=windows-1251); header(Content-Language: bg); Edit this bug report at http://bugs.php.net/?id=11951edit=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 #12581 Updated: boolean fields not imported (patchesenclosed)
On Mon, 6 Aug 2001, Andy wrote:
I didn't think that opening a bug report just to
put a patch in it was correct. Patches are
supposed to be sent to the php-dev mailing list.
Was I wrong?
Yes and no. There are no (that I know of) guidelines
for this. But if a bug report with a patch to a bug
is as valid as a report without a patch, it's even more valuable.
'Duplicate' would be more correct status. In this case,
make the report without a patch the duplicate one.
Ideal solution (IMO) is to have the patch sender to submit a bug report
but have them put the patches somewhere where they can be downloaded.
This way the patch files won't get garbled.
--Jani
On Sun, 05 Aug 2001, Jani Taskinen wrote:
Could you please tell me what is the 'Bogus' in this report?
It's a bug report which happens to have a patch for the bug too.
This is far from bogus report. Reopened.
--Jani
On 5 Aug 2001 [EMAIL PROTECTED] wrote:
ID: 12581
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: dBase related
Operating System: Linux 2.2.16-3
PHP Version: 4.0.6
New Comment:
status - bogus
Previous Comments:
[2001-08-05 16:18:03] [EMAIL PROTECTED]
this is not a bug...already forwarded to [EMAIL PROTECTED]
Thanks for your help, but next time just send it to [EMAIL PROTECTED]
and don't open a bug about it.
[2001-08-05 16:17:47] [EMAIL PROTECTED]
The file name to which the patches apply is ext/dbase/dbase.c.
[2001-08-05 16:16:32] [EMAIL PROTECTED]
Below are patches that fix the problem reported 10/20/2000 in bug report #7374.
The problem is that when boolean (TRUE or FALSE) fields are present in an imported
Dbase file, the value is always imported as FALSE (0). This problem has been present
since 4.0.3. The patches below were generated using distribution 4.0.6.
466,467c466
case 'N': /* FALLS THROUGH */
case 'L': /* FALLS THROUGH */
---
case 'N':
473a473,486
case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
and insert 1 or 0, respectively. db_fdc is the number of
decimals, which we don't care about. 3/14/01 LEW */
if ( (*str_value == 'T') || ( *str_value == 'Y' ) ){
add_next_index_long(return_value, strtol(1, NULL, 10));
} else {
if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
add_next_index_long(return_value, strtol(0, NULL, 10));
}
else {
add_next_index_long(return_value, strtol( , NULL, 10));
}
}
break;
544,545c557
case 'N': /* FALLS THROUGH */
case 'L': /* FALLS THROUGH */
---
case 'N':
551a564,578
case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
and insert 1 or 0, respectively. db_fdc is the number of
decimals, which we don't care about. 3/14/01 LEW */
if ( (*str_value == 'T') || ( *str_value == 'Y') ){
add_assoc_long(return_value, cur_f-db_fname, strtol(1,
NULL, 10));
} else {
if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
add_assoc_long(return_value, cur_f-db_fname,strtol(0,
NULL, 10));
}
else {
add_assoc_long(return_value, cur_f-db_fname,strtol( ,
NULL, 10));
}
}
break;
Edit this bug report at http://bugs.php.net/?id=12581edit=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 #12596: Definition of array using constants in array doesn't work
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.5
PHP Bug Type: Class/Object related
Bug description: Definition of array using constants in array doesn't work
The following piece of code doesn't work:
?
define ('A', 20);
class B
{
var $a = array(A = 10);
}
$b = new B();
var_dump($b);
?
It produces:
object(b)(1) {
[a]=
array(1) {
[A]=
int(10)
}
}
which is unexpected (at least for me).
--
Edit bug report at: http://bugs.php.net/?id=12596edit=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 #12597: AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or /usr/local
From: [EMAIL PROTECTED] Operating system: OpenBSD 2.9-current PHP version: 4.0CVS-2001-08-06 PHP Bug Type: *Configuration Issues Bug description: AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or /usr/local AC_CHECK_LIB in ext/curl/config.m4 fails if cURL is installed elsewhere than /usr/local or /usr, regardless of --with-curl=[directory] setting. The CHECK_LIB macro provides an optional fourth argument which should in this case be set to $CURL_LIBS to make sure the test linking goes ok. Patch at: http://saitti.net/~heko/php/patches/patch-ext_curl_config_m4 Or, inline (let's hope it wraps ok): Index: ext/curl/config.m4 === RCS file: /repository/php4/ext/curl/config.m4,v retrieving revision 1.7 diff -I'$Id' -u -b -B -p -r1.7 config.m4 --- ext/curl/config.m4 27 May 2001 18:52:33 - 1.7 +++ ext/curl/config.m4 6 Aug 2001 13:38:38 - @@ -48,7 +48,7 @@ if test $PHP_CURL != no; then AC_DEFINE(HAVE_CURL,1,[ ]) ],[ AC_MSG_ERROR(There is something wrong. Please check config.log for more information.) - ]) + ], $CURL_LIBS) PHP_EXTENSION(curl, $ext_shared) PHP_SUBST(CURL_SHARED_LIBADD) -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ -- Edit bug report at: http://bugs.php.net/?id=12597edit=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-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote: thies Mon Aug 6 09:36:09 2001 EDT Modified files: /php4/ext/standardbasic_functions.c incomplete_class.c php_incomplete_class.h var.c /php4/ext/wddxwddx.c Log: we can no longer register internal-classes once the script is started. therefore the incomplete class is now registered at MINIT time. How it's not possible all of a sudden? -Andrei I think it would be a good idea. -- Mahatma Gandhi, when asked what he thought of Western civilization... -- 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] Fwd: Re: [thies@thieso.net: Re: [PHP-DEV] incomplete class broken?]
Date: Mon, 06 Aug 2001 16:07:55 +0300 To: Thies C. Arntzen [EMAIL PROTECTED] From: Zeev Suraski [EMAIL PROTECTED] Subject: Re: [[EMAIL PROTECTED]: Re: [PHP-DEV] incomplete class broken?] Cc: Thies C. Arntzen [EMAIL PROTECTED], Andi Gutmans [EMAIL PROTECTED] At 16:00 06/08/2001, Thies C. Arntzen wrote: could you elaborate why it doesn't work (anymore)? Yeah. We no longer go over the entire class/function tables on shutdown, in order to clean the userland classes/functions. We traverse the hash's linked list from its end, as userland entries will always be in the end. When we hit a non userland entry, we stop. This greatly improves performance. It does mean, however, that internal entries should no longer be registered during the request. Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
thies Mon Aug 6 09:36:09 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c incomplete_class.c
php_incomplete_class.h var.c
/php4/ext/wddx wddx.c
Log:
we can no longer register internal-classes once the script is started.
therefore the incomplete class is now registered at MINIT time.
How it's not possible all of a sudden?
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
By the way, if it's really important, we can look into supporting it. The
way it was before - it worked in most cases (assuming you never tried to
use a class before you dl() the corresponding extension), but could result
in crashes in other cases.
I don't think it's very important, though. dl() should most probably be
deprecated from the language, as it's not supported in thread safe mode,
it's slow and insecure. It also creates a host of interesting bugs/buglets
that are difficult to hunt and fix. Other than that - it's great :)
Zeev
At 17:22 06/08/2001, Thies C. Arntzen wrote:
On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
thies Mon Aug 6 09:36:09 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c incomplete_class.c
php_incomplete_class.h var.c
/php4/ext/wddx wddx.c
Log:
we can no longer register internal-classes once the script is started.
therefore the incomplete class is now registered at MINIT time.
How it's not possible all of a sudden?
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
tc
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.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]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
I haven't run into problems with it yet, but I'll keep this in mind, I
guess.
-Andrei
* http://www.zend.com/comm_person.php?id=24 *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Deprecate dl()? I think it's one of the most useful functions... :) -Andrei * Syntactic sugar causes cancer of the semicolon. -- Alan Perlis * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:42 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. -Andrei When we eliminate the impossible, whatever remains, however improbable, must be true. -- Sherlock Holmes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12599: ImageTTFText doesn't open font file
From: [EMAIL PROTECTED] Operating system: Win98 PHP version: 4.0.6 PHP Bug Type: GD related Bug description: ImageTTFText doesn't open font file The following code generates this warning (doesn't happen with 4.0.5): bWarning/b: Could not find/open font in bd:\public_html\image_create.php/b on line b357/bbr Code: ?php Header (Content-type: image/jpeg); $im = imagecreate (400, 30); $black = ImageColorAllocate ($im, 0, 0, 0); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, D:/public_html/fonts/a.ttf, Testing... Omega: #937;); ImageJpeg ($im); ImageDestroy ($im); ? -- Edit bug report at: http://bugs.php.net/?id=12599edit=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-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:52 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. That's one of the places where the PHP/Web functionality and a PHP-standalone functionality collide. In a Web environment, it really makes no sense. The right solution for that is most probably going to be adding a command line option that loads an extension (we already have that for Zend extensions). Loading extensions from within a script is simply a pain to support, and it doesn't really give you anything. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Zeev At 17:55 06/08/2001, Andy wrote: I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Zeev At 17:52 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. -Andrei When we eliminate the impossible, whatever remains, however improbable, must be true. -- Sherlock Holmes -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Can you explain why the difference matters? -Andrei The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian proverb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix
Hey,
The attached patch adds support for passing a variable to
INIT_*CLASS_ENTRY in the name field (instead of just passing a
constant string). I've needed this for a function which provides
API functionality, registering classes with Zend based on the
information passed to it.
-Sterling
Ps: The Midguard folks needed this feature/ran up against this wall
awhile ago as well. Its the only reason I was able to find the
problem without hours of painful debugging ;-)
Index: zend_API.h
===
RCS file: /repository/Zend/zend_API.h,v
retrieving revision 1.101
diff -u -r1.101 zend_API.h
--- zend_API.h 2001/08/06 02:48:55 1.101
+++ zend_API.h 2001/08/06 15:06:42
@@ -82,7 +82,7 @@
#define INIT_CLASS_ENTRY(class_container, class_name, functions) \
{
\
class_container.name = strdup(class_name);
\
- class_container.name_length = sizeof(class_name)-1;
\
+ class_container.name_length = strlen(class_name);
+ \
class_container.builtin_functions = functions;
\
class_container.handle_function_call = NULL;
\
class_container.handle_property_get = NULL;
\
@@ -92,7 +92,7 @@
#define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions,
handle_fcall, handle_propget, handle_propset) \
{
\
class_container.name = strdup(class_name);
\
- class_container.name_length = sizeof(class_name)-1; \
+ class_container.name_length = strlen(class_name); \
class_container.builtin_functions = functions; \
class_container.handle_function_call = handle_fcall;\
class_container.handle_property_get = handle_propget; \
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 18:07 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Can you explain why the difference matters? Sure. dl() means that module_init is done multiple times. It also means that module_shutdown is done multiple times, *and* has to take care of cleaning up after the extension *completely*. That is, clean whatever functions, classes, ini entries and callbacks this function may have registered. Right now, only PHP functions and ini entries (to a degree) are handled properly. Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. - Another buglet resulting from this is the crash in debug mode, in case of a memory leak inside an extension, which is reported in the bugs db. It's no biggy, but also has no good solution. I don't think the solution should be fixing all of the extensions to clean up after themselves, when the only gain is having dl() work, and when using dl() is almost always(*) significantly worse than simply adding the extension to the php.ini file. (*) I can't think of any case in which it isn't, but I'm staying humble :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
See my letter to Andrei. I've yet to see an ISP that (knowingly) allows users to load extensions, and wouldn't agree to add them to the php.ini file. This isn't a case of me saying users don't need X or 95.6% of the scripts out there don't need Y. This is me saying that dl() is *bad*, even if people got used to using it, which is why it should be deprecated. Again, notice that it has been deprecated for a long while in thread-safe mode, which means people who develop under Windows (a huge share) don't have it for over a year. dl() is bad in pretty much every sense, including the new sense you mentioned in your letter - dl()'ing extensions in a shared environment. Forcing the ISP to admit any extensions into the php.ini file before it gets loaded to the server is a good thing. If dl() is one of PEAR's foundations, it's time to dig it up and replace it with something more sound and stable :) Using php.ini for loading extensions should be the way to go. Zeev At 18:18 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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 #12600: unexpected behaviour
From: [EMAIL PROTECTED]
Operating system: linux redhat 7.1
PHP version: 4.0.6
PHP Bug Type: Session related
Bug description: unexpected behaviour
1. when register_globals is off you have to
SET and READ HTTP_SESSION_VARS this is wrong in the docs or
at least confusing (example 1 on
http://www.php.net/manual/en/ref.session.php )
BUG
2. session_register cannot be called from inside another
funcion (when trying a by reference call this generates a
call-time reference error on some servers)
function sess_reg($x){
global $HTTP_SESSION_VARS;
session_register( $HTTP_SESSION_VARS[$x]);
$GLOBALS[$x] = $HTTP_SESSION_VARS[$x];
}
//session_start();
sess_reg(foo);
echo $foo++;
when using session_register($HTTP_SESSION_VARS[$x]);
the variable is NOT registered. and when used by reference
(as in example above) generates a Warning: Call-time
pass-by-reference has been deprecated -
argument passed by value;
Tr909
--
Edit bug report at: http://bugs.php.net/?id=12600edit=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] INIT_OVERLOADED_CLASS_ENTRY fix
It's not a big deal and we can commit it (as it's done in the 'put-expensive-operations-here' part of PHP, the module-init, hint hint :). However, is it really necessary? Zeev At 05:53 06/08/2001, Sterling Hughes wrote: Hey, The attached patch adds support for passing a variable to INIT_*CLASS_ENTRY in the name field (instead of just passing a constant string). I've needed this for a function which provides API functionality, registering classes with Zend based on the information passed to it. -Sterling Ps: The Midguard folks needed this feature/ran up against this wall awhile ago as well. Its the only reason I was able to find the problem without hours of painful debugging ;-) -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- 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 #12597 Updated: AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or /usr/local
ID: 12597 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: *Configuration Issues Operating System: OpenBSD 2.9-current PHP Version: 4.0CVS-2001-08-06 New Comment: Fixed in CVS. You also need to have -L$CURL_DIR/lib after the $CURL_LIBS since the path is not necessarily given by curl-config. --Jani Previous Comments: [2001-08-06 09:58:09] [EMAIL PROTECTED] AC_CHECK_LIB in ext/curl/config.m4 fails if cURL is installed elsewhere than /usr/local or /usr, regardless of --with-curl=[directory] setting. The CHECK_LIB macro provides an optional fourth argument which should in this case be set to $CURL_LIBS to make sure the test linking goes ok. Patch at: http://saitti.net/~heko/php/patches/patch-ext_curl_config_m4 Or, inline (let's hope it wraps ok): Index: ext/curl/config.m4 === RCS file: /repository/php4/ext/curl/config.m4,v retrieving revision 1.7 diff -I'$Id' -u -b -B -p -r1.7 config.m4 --- ext/curl/config.m4 27 May 2001 18:52:33 - 1.7 +++ ext/curl/config.m4 6 Aug 2001 13:38:38 - @@ -48,7 +48,7 @@ if test $PHP_CURL != no; then AC_DEFINE(HAVE_CURL,1,[ ]) ],[ AC_MSG_ERROR(There is something wrong. Please check config.log for more information.) - ]) + ], $CURL_LIBS) PHP_EXTENSION(curl, $ext_shared) PHP_SUBST(CURL_SHARED_LIBADD) -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ Edit this bug report at http://bugs.php.net/?id=12597edit=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 #12599 Updated: ImageTTFText doesn't open font file
ID: 12599 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: GD related Operating System: Win98 PHP Version: 4.0.6 New Comment: This has been fixed in CVS already. Next time, use the search before submitting bug reports.. --Jani Previous Comments: [2001-08-06 10:56:33] [EMAIL PROTECTED] The following code generates this warning (doesn't happen with 4.0.5): bWarning/b: Could not find/open font in bd:\public_html\image_create.php/b on line b357/bbr Code: ?php Header (Content-type: image/jpeg); $im = imagecreate (400, 30); $black = ImageColorAllocate ($im, 0, 0, 0); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, D:/public_html/fonts/a.ttf, Testing... Omega: #937;); ImageJpeg ($im); ImageDestroy ($im); ? Edit this bug report at http://bugs.php.net/?id=12599edit=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 #12601: Error loading oci8.dll, a entry point is missing .
From: [EMAIL PROTECTED] Operating system: windows 2000 profesional PHP version: 4.0.6 PHP Bug Type: OCI8 related Bug description: Error loading oci8.dll, a entry point is missing . Error loading oci8.dll, a entry point is missing ... to procedure ocilobopen in oci.dll he a wanrning unable to load dynamic library, but it's there. -- Edit bug report at: http://bugs.php.net/?id=12601edit=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] INIT_OVERLOADED_CLASS_ENTRY fix
On Mon, 6 Aug 2001, Zeev Suraski wrote:
It's not a big deal and we can commit it (as it's done in the
'put-expensive-operations-here' part of PHP, the module-init, hint hint :).
;)
However, is it really necessary?
Well, I have the following function (there maybe bugs, I'm still
debugging it:
/* {{{ adt_status_t adt_register_type(const char *type_name, adt_type *p)
Register a new abstract data type */
ADT_DECLARE(adt_status_t) adt_register_type(adt_type *p)
{
zend_class_entry ce;
TSRMLS_FETCH();
if (zend_hash_update(ADTG(types),
p-name,
strlen(p-name) + 1,
(void *) p,
sizeof(adt_type),
NULL) == FAILURE) {
php_error(E_WARNING, Cannot register type: %s, p-name);
return -1;
}
p-le_id = zend_register_list_destructors_ex(p-le_dtor, NULL, p-le_name,
global_module_number);
INIT_OVERLOADED_CLASS_ENTRY(ce, p-name, NULL, adt_method_call_handler,
adt_property_get_handler, adt_property_set_handler);
p-ce = zend_register_internal_class_ex(ce, NULL, NULL TSRMLS_CC);
return 0;
}
/* }}} */
That's used to register the class. If you can think of another way
to do (*don't* say macro ;-), then I'd be more than willing to hear
it, but otherwise...
-Sterling
Zeev
At 05:53 06/08/2001, Sterling Hughes wrote:
Hey,
The attached patch adds support for passing a variable to
INIT_*CLASS_ENTRY in the name field (instead of just passing a
constant string). I've needed this for a function which provides
API functionality, registering classes with Zend based on the
information passed to it.
-Sterling
Ps: The Midguard folks needed this feature/ran up against this wall
awhile ago as well. Its the only reason I was able to find the
problem without hours of painful debugging ;-)
--
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]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 10:34:34AM -0500, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. tc -- 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] INIT_OVERLOADED_CLASS_ENTRY fix
On Sun, 05 Aug 2001, Sterling Hughes wrote: That's used to register the class. If you can think of another way to do (*don't* say macro ;-), then I'd be more than willing to hear it, but otherwise... You can just initialize the class entry manually. -Andrei Everything is a matter of a little programming -- Rasmus Lerdorf -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote: don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. Hmm, right, they don't have module_number.. -Andrei * Why is it always Segmentation's fault? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. Also, just to mention, right now it might not be that big a deal to load them all in php.ini (well something as big PHP-GTK would be, but...), however, as PHP gets more and more extensions written in C, there needs to be this functionality. All other programming languages that I know of have the functionality as well -Sterling -- 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 #12603: incorrect --enable-native-ttf, correct - --enable-native-tt
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: *Configuration Issues Bug description: incorrect --enable-native-ttf, correct - --enable-native-tt in configure mistake in --enable-native-tt (--enable-native-ttf) -- Edit bug report at: http://bugs.php.net/?id=12603edit=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 #12603 Updated: incorrect --enable-native-ttf, correct - --enable-native-tt
ID: 12603 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: *Configuration Issues Operating System: PHP Version: 4.0.6 New Comment: This has been fixed in the CVS for a LOOONG time... Previous Comments: [2001-08-06 12:06:42] [EMAIL PROTECTED] in configure mistake in --enable-native-tt (--enable-native-ttf) Edit this bug report at http://bugs.php.net/?id=12603edit=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] INIT_OVERLOADED_CLASS_ENTRY fix
On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Sun, 05 Aug 2001, Sterling Hughes wrote: That's used to register the class. If you can think of another way to do (*don't* say macro ;-), then I'd be more than willing to hear it, but otherwise... You can just initialize the class entry manually. Yeah, but that sorta eliminates the use of the macro in the first place :) -Andrei Everything is a matter of a little programming -- Rasmus Lerdorf Wow, Rasmus gets his first quote in the Zmievski list. ;-) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 06:30 06/08/2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. Also, just to mention, right now it might not be that big a deal to load them all in php.ini (well something as big PHP-GTK would be, but...), however, as PHP gets more and more extensions written in C, there needs to be this functionality. Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. At 18:34 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. I thought you meant significantly worse run-time perfomance because the engine can't optimize for function arguments, not because of what kind of MINIT an extension has. We're still talking about standalone PHP binary here. -Andrei A room without books is like a body without a soul. -- Marcus Tullius Cicero (106-43 B.C.) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12599 Updated: ImageTTFText doesn't open font file
I did search it before, with no results. ID: 12599 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: GD related Operating System: Win98 PHP Version: 4.0.6 New Comment: This has been fixed in CVS already. Next time, use the search before submitting bug reports.. --Jani Previous Comments: -- -- [2001-08-06 10:56:33] [EMAIL PROTECTED] The following code generates this warning (doesn't happen with 4.0.5): bWarning/b: Could not find/open font in bd:\public_html\image_create.php/b on line b357/bbr Code: ?php Header (Content-type: image/jpeg); $im = imagecreate (400, 30); $black = ImageColorAllocate ($im, 0, 0, 0); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, D:/public_html/fonts/a.ttf, Testing... Omega: #937;); ImageJpeg ($im); ImageDestroy ($im); ? -- -- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/? id=12599edit=2 - Carlos Viana [[EMAIL PROTECTED]] [[EMAIL PROTECTED]] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] First snapshot of the Universe PHP extension (PHP-MICO binding)
Hi! I'm proud to present the first snapshot of the Universe PHP extension. What is it? It is a CORBA connection using MICO as ORB. It is intended to replace the exisiting PHP extension Satellite. You can access remote or local CORBA objects, and you can create CORBA objects in PHP code! Information, download and demo at: http://universe.2good.nu/ Universe not ready for production environment yet... it leaks memory! :-( If the PHP Group would like me to submit it to the PHP CVS, I will! :-) Regards, -\- David Eriksson -/- An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. - Richard B. Johnson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:29 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. I thought you meant significantly worse run-time perfomance because the engine can't optimize for function arguments, not because of what kind of MINIT an extension has. We're still talking about standalone PHP binary here. Ah. Well, YMMV. If you have repeated calls to functions (not class methods, these are not optimized), it can be quite significant - you have an extra opcode that includes some stack manipulation, string duplication and strtolower of the function name, and slower pass_param opcodes. I never actually benchmarked it, but it can be quite significant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) Zeev -- 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 #12599 Updated: ImageTTFText doesn't open font file
Well, then you didn't search for the right thing... On Mon, 06 Aug 2001, Carlos Viana wrote: I did search it before, with no results. ID: 12599 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: GD related Operating System: Win98 PHP Version: 4.0.6 New Comment: This has been fixed in CVS already. Next time, use the search before submitting bug reports.. --Jani Previous Comments: -- -- [2001-08-06 10:56:33] [EMAIL PROTECTED] The following code generates this warning (doesn't happen with 4.0.5): bWarning/b: Could not find/open font in bd:\public_html\image_create.php/b on line b357/bbr Code: ?php Header (Content-type: image/jpeg); $im = imagecreate (400, 30); $black = ImageColorAllocate ($im, 0, 0, 0); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, D:/public_html/fonts/a.ttf, Testing... Omega: #937;); ImageJpeg ($im); ImageDestroy ($im); ? -- -- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/? id=12599edit=2 - Carlos Viana [[EMAIL PROTECTED]] [[EMAIL PROTECTED]] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? -Andrei * Life may be expensive, but it includes an annual free trip around the sun. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) -Andrei * Marriage is not a word. It's a sentence. Life-long sentence. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:45 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) :) Anyway, I'm off for a few hours now, reinstalling my machine. I'll answer anything that comes up when I get back ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Zeev Suraski wrote: At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Interesting -- what about the extra weight of 50 extensions instead of just one? -Sterling -- 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 #11933 Updated: array_map causes segfault
ID: 11933 Updated by: andrei Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Old Operating System: Debian GNU/Linux sid (kernel 2 Operating System: Debian GNU/Linux \sid\ (kernel 2 PHP Version: 4.0.6 New Comment: Are you running Zend optimizer by any chance? Previous Comments: [2001-07-06 10:25:03] [EMAIL PROTECTED] I have a script which seems to arbitrarily crash. Removing all uses of array_map corrects the problem, even though the apparent point of crash isn't anywhere near a call to array_map. I'd attach the script but it's rather long and I don't have time to whittle it down to a minimum case. gdb backtrace: #0 0x4024e390 in call_user_function_ex () from /usr/lib/apache/1.3/libphp4.so #1 0x402967eb in php_if_array_map () from /usr/lib/apache/1.3/libphp4.so #2 0x40247d09 in execute () from /usr/lib/apache/1.3/libphp4.so #3 0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so #4 0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so #5 0x4025654e in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so #6 0x40268224 in php_execute_script () from /usr/lib/apache/1.3/libphp4.so #7 0x4026488f in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so #8 0x4026526e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so #9 0x402652aa in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so #10 0x8054204 in ap_invoke_handler () #11 0x806306c in ap_some_auth_required () #12 0x80630c8 in ap_process_request () #13 0x805cc29 in ap_child_terminate () #14 0x805cdbc in ap_child_terminate () #15 0x805ced9 in ap_child_terminate () #16 0x805d395 in ap_child_terminate () #17 0x805da5d in main () #18 0x400e438b in __libc_start_main () from /lib/libc.so.6 Edit this bug report at http://bugs.php.net/?id=11933edit=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 #12477 Updated: preg_replace evaluates dollar signs as variables (eg $1,000 becomes ,000)
ID: 12477
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux and SCO
PHP Version: 4.0.6
New Comment:
That's right, you need to escape $ in your replacement strings.
Previous Comments:
[2001-07-31 00:40:54] [EMAIL PROTECTED]
The setup for my templating system:
$template=array(
/({PAGETOP})/,
/({PAGENAVBAR})/,
/({PAGEMAIN})/,
/({PAGELINKS})/,
/({PAGESPACE})/,
/({PAGETEXT})/,
/({PAGENEWS})/,
/({PAGEBOTTOM})/,
/({PAGEDATA})/
);
$pagevars=array(
PAGETOP = get_page($site-page_top),
PAGENAVBAR = get_page($site-page_top),
PAGEMAIN = get_page($site-page_main),
PAGELINKS = get_page($site-page_links),,
PAGESPACE = get_page($site-page_space),
PAGETEXT = get_page($site-page_text),
PAGENEWS = get_page($site-page_news),,
PAGEBOTTOM = get_page($site-page_bottom),
PAGEDATA =
);
$page = {PAGETOP}{PAGENAVBAR}{PAGEMAIN}{PAGEBOTTOM};
$page = preg_replace($template,$pagevars,$page);
echo $page;
Basically each physical page referenced via the get_page function is a text template
that may contain HTML, text or variables in the form {VAR}.
Eventually content from a database ends up in a variable called PAGEDATA which is in
the template stored in the page main variable.
The problem:
PAGEDATA ends up containing page text and it has something like would cost around
$16,000 to complete in that text.
When the preg_replace is performed, something somewhere is assuming that $16 is a
variable (which doesn't exist) and the text ends up as would cost around ,000 to
complete
Edit this bug report at http://bugs.php.net/?id=12477edit=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 #11933 Updated: array_map causes segfault
ID: 11933 Updated by: andy Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Reproducible crash Old Operating System: Debian GNU/Linux sid (kernel 2 Operating System: Debian GNU/Linux sid (kernel 2 PHP Version: 4.0.6 New Comment: status - feedback Previous Comments: [2001-08-06 12:47:45] [EMAIL PROTECTED] Are you running Zend optimizer by any chance? [2001-07-06 10:25:03] [EMAIL PROTECTED] I have a script which seems to arbitrarily crash. Removing all uses of array_map corrects the problem, even though the apparent point of crash isn't anywhere near a call to array_map. I'd attach the script but it's rather long and I don't have time to whittle it down to a minimum case. gdb backtrace: #0 0x4024e390 in call_user_function_ex () from /usr/lib/apache/1.3/libphp4.so #1 0x402967eb in php_if_array_map () from /usr/lib/apache/1.3/libphp4.so #2 0x40247d09 in execute () from /usr/lib/apache/1.3/libphp4.so #3 0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so #4 0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so #5 0x4025654e in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so #6 0x40268224 in php_execute_script () from /usr/lib/apache/1.3/libphp4.so #7 0x4026488f in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so #8 0x4026526e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so #9 0x402652aa in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so #10 0x8054204 in ap_invoke_handler () #11 0x806306c in ap_some_auth_required () #12 0x80630c8 in ap_process_request () #13 0x805cc29 in ap_child_terminate () #14 0x805cdbc in ap_child_terminate () #15 0x805ced9 in ap_child_terminate () #16 0x805d395 in ap_child_terminate () #17 0x805da5d in main () #18 0x400e438b in __libc_start_main () from /lib/libc.so.6 Edit this bug report at http://bugs.php.net/?id=11933edit=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 #12140 Updated: pcre_replace change behavior with \
ID: 12140
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System:
PHP Version: 4.0.6
New Comment:
That's right. Your turns into by the time PHP string parsing is done
with it. Then the extension looks at it and sees two escaped backslashes so that's
what you get - two backslashes.
In general, use str_replace() for things like that.
Previous Comments:
[2001-07-13 08:51:59] [EMAIL PROTECTED]
task:
need replace \ (one) to (four)
On php.4.0.5 work:
$val1=preg_replace('/\\\/',,$val);
On php 4.0.6 work:
$val1=preg_replace('/\\\/',,$val);
Edit this bug report at http://bugs.php.net/?id=12140edit=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 #12518 Updated: ocifreestatment doesn't free the Oracle cursor and so you run out of cursors
ID: 12518 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 4.0.6 New Comment: I have a long-running PHP script that eventually comes up with: Failed execution, error: ORA-00604: error occurred at recursive SQL level 2 ORA-01000: maximum open cursors exceeded. I don't explicitly use any cursors in this script btw. In addition I found (via a web search) that someone else has been experiencing the same thing. However, in response to your request I've been trying to build a test script to leak cursors and reproduce the problem, unfortunately, thus far, even deliberately leaking cursors is not producing it. :( Previous Comments: [2001-08-01 16:18:03] [EMAIL PROTECTED] what makes you belive it doesn't work? please send me a short testcase that shows leakage of resources. [2001-08-01 13:20:01] [EMAIL PROTECTED] the ocifreestatment function doesn't actually free the Oracle cursor, these are only freed when the script exits. While this isn't a problem when using PHP as a web page it is a problem if you have a command line script that has to perform thousands (or tens of thousands) of queries eventually the open_cursors limit is exceeded and all further queries fail. The same appears to be true with connections. Edit this bug report at http://bugs.php.net/?id=12518edit=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 #11594 Updated: preg_replace is not working with backslash $
ID: 11594
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Solaris
PHP Version: 4.0.5
New Comment:
You need to use '$' as you replacement string.
Previous Comments:
[2001-06-20 17:40:55] [EMAIL PROTECTED]
I'm trying to use preg_replace to replace $ with \$.
Here is a sample script:
?
$data = '$_hello_$world';
$data = preg_replace('/\$/i','\$',$data);
print data : $data\n;
?
I expect the script to output \$_hello_\$world. However, version 4.0.5 is outputing
$_hello_$world.
This worked in version 4.0.4
It possible this bug is related to bug# 10668
Edit this bug report at http://bugs.php.net/?id=11594edit=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 #11236 Updated: addslashes() before preg_replace() gives parse error in regexp
ID: 11236
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.0.5
New Comment:
This works in latest CVS - try upgrading to 4.0.6 or later.
Previous Comments:
[2001-06-11 10:04:46] [EMAIL PROTECTED]
Just an update -- this issue seems to be to do with having lots of single quotes (')
in the string. It has also been an issue in strings other than the one shown in my
first post.
6 quotes seems to be the limit of what it can handle.
John
[2001-06-01 07:11:28] [EMAIL PROTECTED]
This issue seems to only affect PHP 4.0.5, not earlier versions, as far as I can tell.
The following code gives an error:
?
$string=
[code]
EXEC sp_addlinkedserver 'TillDB', 'Access 2000', 'Microsoft.Jet.OLEDB.4.0',
'\\till01\C\endx\data\ct.mdb'
EXEC sp_addlinkedsrvlogin 'TillDB', false, NULL, 'Admin', NULL
EXEC sp_dropserver 'TIllDB', 'droplogins'
[/code]
;
function stripbrsfromcode($str) {
return ($str);
}
//$string=str_replace(',\',$string);
$string=addslashes($string);
echo $string;
$string=preg_replace(/(\[)(code)(])(\r\n)*(.*)(\[\/code\])/esiU,stripbrsfromcode('\\5'),$string);
echo $string;
?
The error is as follows:
[code] EXEC sp_addlinkedserver \'TillDB\', \'Access 2000\',
\'Microsoft.Jet.OLEDB.4.0\', \'\till01\C\endx\data\ct.mdb\' EXEC sp_addlinkedsrvlogin
\'TillDB\', false, NULL, \'Admin\', NULL EXEC sp_dropserver \'TIllDB\', \'droplogins\'
[/code]
Parse error: parse error in /usr/local/apache/htdocs/test.php(24) : regexp code on
line 5
Fatal error: Failed evaluating code: stripbrsfromcode(' EXEC sp_addlinkedserver
\\\'TillDB\\\', \\\'Access 2000\\\', \\\'Microsoft.Jet.OLEDB.4.0\\\',
\\\'\\till01\\C\\endx\\data\\ct.mdb\\\' EXEC sp_addlinkedsrvlogin \\\'TillDB\\\',
false, NULL, \\\'Admin\\\', NULL EXEC sp_dropserver \\'TIllDB\\', \\'droplogins\\' ')
in /usr/local/apache/htdocs/test.php on line 24
Let me know if you need other info. I have seen this problem on two independant
configurations, so I am fairly sure it is not the server.
phpinfo here:
http://161.58.186.97/phpinfo.php
Edit this bug report at http://bugs.php.net/?id=11236edit=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 #10669 Updated: Problem with preg_split
ID: 10669
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux-2.2.19
PHP Version: 4.0.5
New Comment:
This should work in 4.0.6 and later.
Previous Comments:
[2001-05-04 11:48:56] [EMAIL PROTECTED]
Look at the following code:
?
$price = 66950;
$formatado = preg_split ('//', $price, 0, PREG_SPLIT_NO_EMPTY);
$formatado_reverso = array_reverse ($formatado );
$escalar = sizeof($formatado);
echo $escalar;
?
In php4.0.4pl1 the result is 5, in php4.0.5 the result is 1.
I also tried version 1.92 in CVS of /ext/pcre/php_pcre.c but I got the same result.
Is this a bug or a change in design ?
Thanks
Renato - Brasil.
Edit this bug report at http://bugs.php.net/?id=10669edit=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 #10179 Updated: repetition quantifiers
ID: 10179
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: SuSE7.0
PHP Version: 4.0.4pl1
New Comment:
{,10} means match up to 10 which includes 0 matches.
Previous Comments:
[2001-04-05 05:29:59] [EMAIL PROTECTED]
I am not sure if it's a bug or misinterpretation on my side
but I expect something like /[0-9]{,10}/ to match
a number at most 10 chars.
the following snipet reproduces the problem, if any:
if (preg_match('/^[0-9]{,10}$/',3)) {
echo matched;
} else {
echo not matched;
}
outputs not matched.
And if I write {1,10} it matches. So the question is,
is the minimum quantifier mandatory?
ciao
Edit this bug report at http://bugs.php.net/?id=10179edit=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: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Zeev Suraski wrote: At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Interesting -- what about the extra weight of 50 extensions instead of just one? I think the disk weights about the same regardless of the data inside it :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: I think the disk weights about the same regardless of the data inside it :) Yes, but 50 extensions will consume more memory than 1. -Andrei In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: I think the disk weights about the same regardless of the data inside it :) Yes, but 50 extensions will consume more memory than 1. Nothing noticable, really. Unless you allocate dozens of megabytes in your extension, it won't pose any significant memory load, as it only loads once, shared across all processes/threads of the server. This is not true if you dl() it, by the way. Zeev -- Zeev Suraski [EMAIL PROTECTED] http://www.zend.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] Re: Bug #12480 Updated: array_merge_recursive() clobbers existing numeric keys
On Aug 06, Bug Database wrote: ID: 12480 Updated by: andrei Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Arrays related Operating System: FreeBSD PHP Version: 4.0.6 New Comment: array_merge* functions are not meant to preserve numeric keys. uhm, forgive me for being stupid, but why not? I was trying to use numeric keys to store the id of db records that didn't start at 0. using array_merge_recursive destroyed this information, so I have to store it in the array itself, which in turn means I can't do stuff like if ($records[$id]['someval']), or ksort on $records, or do foreach ($records as $id = $values) and other nice things like that after I've used array_merge_recursive. and do you think, perhaps, it might be worth noting this in the man pages? regards, peter lowe. Previous Comments: [2001-07-31 05:14:43] [EMAIL PROTECTED] if any of the keys of the first level of arrays are numeric, using array_merge_recursive() will renumber them to start at 0. this destroys keys that are used to record id numbers, etc. [mini:pgl]:~/public_html $ cat test.php #!/usr/local/bin/php -q ? $b[a][4] = 1; $a[3][4] = 2; print_r(array_merge_recursive($a, $b)); ? [mini:pgl]:~/public_html $ ./test.php Array ( [0] = Array ( [4] = 2 ) [a] = Array ( [4] = 1 ) ) ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=12480edit=2 -- This is not the signature you are looking for. Move along. -- 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 #12518 Updated: ocifreestatment doesn't free the Oracle cursor and so you run out of cursors
ID: 12518 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: OCI8 related Operating System: Linux PHP Version: 4.0.6 New Comment: With the help of v$open_cursor I've tracked down the problem and it was a case of user error, my apologies for having taken up your time. Previous Comments: [2001-08-06 12:59:04] [EMAIL PROTECTED] I have a long-running PHP script that eventually comes up with: Failed execution, error: ORA-00604: error occurred at recursive SQL level 2 ORA-01000: maximum open cursors exceeded. I don't explicitly use any cursors in this script btw. In addition I found (via a web search) that someone else has been experiencing the same thing. However, in response to your request I've been trying to build a test script to leak cursors and reproduce the problem, unfortunately, thus far, even deliberately leaking cursors is not producing it. :( [2001-08-01 16:18:03] [EMAIL PROTECTED] what makes you belive it doesn't work? please send me a short testcase that shows leakage of resources. [2001-08-01 13:20:01] [EMAIL PROTECTED] the ocifreestatment function doesn't actually free the Oracle cursor, these are only freed when the script exits. While this isn't a problem when using PHP as a web page it is a problem if you have a command line script that has to perform thousands (or tens of thousands) of queries eventually the open_cursors limit is exceeded and all further queries fail. The same appears to be true with connections. Edit this bug report at http://bugs.php.net/?id=12518edit=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]
