#45457 [Com]: compilation error
ID: 45457 Comment by: mirc-m at mail dot ru Reported By: dmiry at conft dot org Status: No Feedback Bug Type: Compile Failure Operating System: debian 4.0 PHP Version: 5.2.6 New Comment: 'make clean' helps to solve the compile issue in my case but it looks strange that pure release just downloaded requires to be cleared. Previous Comments: [2008-07-16 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-08 15:00:07] [EMAIL PROTECTED] Looks like you didn't clean after changing the configure line. Please make sure you're running make clean (or cvsclean) before building again. [2008-07-08 14:33:58] dmiry at conft dot org Description: cannot compile php 5.2.6 on debian etch 4.0, get a compilation error, compiling with the following configuration: ./configure \ --with-apxs2=/usr/bin/apxs2 \ --with-gd \ --with-gd-dir=/usr/lib \ --with-gettext \ --with-jpeg-dir=/usr/lib \ --with-freetype \ --with-freetype-dir=/usr/lib \ --with-kerberos \ --with-mcrypt \ --with-mhash \ --with-mysql=/usr/local/mysql \ --with-pear \ --with-png-dir=/usr//lib \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-openssl \ --with-mysqli=/usr/bin/mysql_config \ --enable-bcmath \ --enable-calendar \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-track-vars \ --enable-mbstring Actual result: -- sapi/cli/.libs/php_cli.o: In function `sapi_cli_deactivate': /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:320: undefined reference to `sapi_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:322: undefined reference to `sapi_globals' sapi/cli/.libs/php_cli.o: In function `main': /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:728: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1317: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1324: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:729: undefined reference to `compiler_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:730: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:805: undefined reference to `sapi_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:828: undefined reference to `compiler_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:997: undefined reference to `compiler_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1029: undefined reference to `sapi_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1030: undefined reference to `sapi_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1032: undefined reference to `sapi_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1043: undefined reference to `compiler_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1055: undefined reference to `core_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1141: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1199: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1210: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1221: undefined reference to `compiler_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1223: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1269: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1273: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1276: undefined reference to `executor_globals' /usr/local/src/php-5.2.6/sapi/cli/php_cli.c:1277: undefined reference to `executor_globals' sapi/cli/.libs/php_cli.o:(.debug_info+0x46f3): undefined reference to `sapi_globals' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=45457&edit=1
#45715 [NEW]: CPU utilization goes high of application server and not the mysql server
From: lavesh dot rawat at gmail dot com
Operating system: Linux
PHP version: 5.2CVS-2008-08-05 (CVS)
PHP Bug Type: Streams related
Bug description: CPU utilization goes high of application server and not the
mysql server
Description:
popen commnads uses cpu of application server rather than database
server.
when I run command popen("php -q filename.php");
where filename.php have some query whose database connection goes to
some other database.
CPU Utilization of current server server goes high istead of mysql server.
Expected result:
CPU Utilization of current server server should not be much affected as
queries are running on mysql server which is normally the case when we run
queries.
--
Edit bug report at http://bugs.php.net/?id=45715&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45715&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45715&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45715&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45715&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45715&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45715&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45715&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45715&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45715&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45715&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45715&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45715&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45715&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45715&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45715&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45715&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45715&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45715&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45715&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45715&r=mysqlcfg
#45716 [NEW]: Addition and minus operators do not work properly when appended to a string
From: pasamio at gmail dot com Operating system: Linux 2.6.5-7.191-smp PHP version: 5.2.6 PHP Bug Type: Scripting Engine problem Bug description: Addition and minus operators do not work properly when appended to a string Description: When using a simple addition or minus operator that is prepended by a string and concatenated to it will fail to work properly if the string has a value. When the string is empty (e.g. '' or ' ') it will work properly. The multiplication and division functions operate appropriately. Reproduce code: --- php bug-minus.php Addition Test Test 1: 12 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test Test 1: 8 Test 2: 8 Test 3: 8 Test 4: 8 Actual result: -- [EMAIL PROTECTED]:~/public_html/testing> php bug-minus.php Addition Test 2 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test -2 Test 2: 8 Test 3: 8 Test 4: 8 -- Edit bug report at http://bugs.php.net/?id=45716&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45716&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45716&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45716&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45716&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45716&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45716&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45716&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45716&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45716&r=support Expected behavior:http://bugs.php.net/fix.php?id=45716&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45716&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45716&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45716&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45716&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45716&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45716&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45716&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45716&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45716&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45716&r=mysqlcfg
#45716 [Opn->Bgs]: Addition and minus operators do not work properly when appended to a string
ID: 45716 Updated by: [EMAIL PROTECTED] Reported By: pasamio at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.6.5-7.191-smp PHP Version: 5.2.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is because of operator precedence, see: http://no2.php.net/manual/en/language.operators.php Previous Comments: [2008-08-05 07:39:52] pasamio at gmail dot com Description: When using a simple addition or minus operator that is prepended by a string and concatenated to it will fail to work properly if the string has a value. When the string is empty (e.g. '' or ' ') it will work properly. The multiplication and division functions operate appropriately. Reproduce code: --- php bug-minus.php Addition Test Test 1: 12 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test Test 1: 8 Test 2: 8 Test 3: 8 Test 4: 8 Actual result: -- [EMAIL PROTECTED]:~/public_html/testing> php bug-minus.php Addition Test 2 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test -2 Test 2: 8 Test 3: 8 Test 4: 8 -- Edit this bug report at http://bugs.php.net/?id=45716&edit=1
#45716 [Bgs]: Addition and minus operators do not work properly when appended to a string
ID: 45716 User updated by: pasamio at gmail dot com Reported By: pasamio at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.6.5-7.191-smp PHP Version: 5.2.6 New Comment: Apologies, didn't think that it would have the same precendence given that the two operators do two completely different type conversions (one to numeric and the other to a string). I guess thats something copied from Perl which appears to use a similar methodology. Previous Comments: [2008-08-05 07:42:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is because of operator precedence, see: http://no2.php.net/manual/en/language.operators.php [2008-08-05 07:39:52] pasamio at gmail dot com Description: When using a simple addition or minus operator that is prepended by a string and concatenated to it will fail to work properly if the string has a value. When the string is empty (e.g. '' or ' ') it will work properly. The multiplication and division functions operate appropriately. Reproduce code: --- php bug-minus.php Addition Test Test 1: 12 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test Test 1: 8 Test 2: 8 Test 3: 8 Test 4: 8 Actual result: -- [EMAIL PROTECTED]:~/public_html/testing> php bug-minus.php Addition Test 2 Test 2: 12 Test 3: 12 Test 4: 12 Subtraction Test -2 Test 2: 8 Test 3: 8 Test 4: 8 -- Edit this bug report at http://bugs.php.net/?id=45716&edit=1
#45718 [NEW]: h
From: h at h dot com Operating system: h PHP version: 4.4.8 PHP Bug Type: *General Issues Bug description: h Description: h Reproduce code: --- h Expected result: h -- Edit bug report at http://bugs.php.net/?id=45718&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45718&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45718&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45718&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45718&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45718&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45718&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45718&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45718&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45718&r=support Expected behavior:http://bugs.php.net/fix.php?id=45718&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45718&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45718&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45718&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45718&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45718&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45718&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45718&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45718&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45718&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45718&r=mysqlcfg
#45717 [NEW]: Fileinfo/libmagic build fails, missing err.h and getopt.h
From: Bjorn dot Wiberg at its dot uu dot se Operating system: IBM AIX 5.3 5300-08-01-0819 PHP version: 5.3.0alpha1 PHP Bug Type: Compile Failure Bug description: Fileinfo/libmagic build fails, missing err.h and getopt.h Description: The bundled Fileinfo extension comes with libmagic sources, which look for err.h and getopt.h, which appear not to exist on IBM AIX systems. Is there perhaps a possibility of pointing to an existing libmagic installation? I have libmagic installed in /usr/local but cannot find a way to make the bundled Fileinfo extension use that one. Currently (5.2.6) we're using the Fileinfo 1.0.4 extension with the existing libmagic (file 4.21) installation, and that works fine... but would like to be able to use the Fileinfo bundled with PHP 5.3 instead. Reproduce code: --- #! /bin/sh # # Created by configure CC='gcc' \ './configure' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-ttf' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Expected result: Successful compilation. Actual result: -- ---8<--- begin excerpt ---8<--- gcc -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic -Iext/fileinfo/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c -DPIC -o ext/fileinfo/libmagic/.libs/getopt_long.o /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:33:17: error: err.h: No such file or directory /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:35:20: error: getopt.h: No such file or directory /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:47: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:48: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:49: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:76: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:77: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:78: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c: In function 'getopt_internal': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:250: warning: implicit declaration of function 'warnx' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c: In function 'getopt_long': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:392: error: invalid use of undefined type 'struct option' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:392: error: dereferencing pointer to incomplete type /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:394: error: invalid use of undefined type 'struct option' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:394: error: dereferencing point
#45717 [Opn->Asn]: Fileinfo/libmagic build fails, missing err.h and getopt.h
ID: 45717 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: IBM AIX 5.3 5300-08-01-0819 PHP Version: 5.3.0alpha1 -Assigned To: +Assigned To: derick Previous Comments: [2008-08-05 09:01:42] Bjorn dot Wiberg at its dot uu dot se Description: The bundled Fileinfo extension comes with libmagic sources, which look for err.h and getopt.h, which appear not to exist on IBM AIX systems. Is there perhaps a possibility of pointing to an existing libmagic installation? I have libmagic installed in /usr/local but cannot find a way to make the bundled Fileinfo extension use that one. Currently (5.2.6) we're using the Fileinfo 1.0.4 extension with the existing libmagic (file 4.21) installation, and that works fine... but would like to be able to use the Fileinfo bundled with PHP 5.3 instead. Reproduce code: --- #! /bin/sh # # Created by configure CC='gcc' \ './configure' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-ttf' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Expected result: Successful compilation. Actual result: -- ---8<--- begin excerpt ---8<--- gcc -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic -Iext/fileinfo/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c -DPIC -o ext/fileinfo/libmagic/.libs/getopt_long.o /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:33:17: error: err.h: No such file or directory /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:35:20: error: getopt.h: No such file or directory /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:47: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:48: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:49: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:76: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:77: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:78: error: parse error before '__P' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c: In function 'getopt_internal': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:250: warning: implicit declaration of function 'warnx' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c: In function 'getopt_long': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:392: error: invalid use of undefined type 'struct option' /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/fileinfo/libmagic/getopt_long.c:392: error: dereferencing pointer to incomplete typ
#44998 [Opn->Asn]: mysqli_real_escape_string not properly escaping null characters
ID: 44998
Updated by: [EMAIL PROTECTED]
Reported By: djneoform at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
Operating System: Win2003 Standard
PHP Version: 5.2.6
Assigned To: andrey
Previous Comments:
[2008-07-24 14:23:20] djneoform at gmail dot com
The resulting dump for the table once i run the script.
/*
MySQL Data Transfer
Source Host: localhost
Source Database: phpneoform
Target Host: localhost
Target Database: phpneoform
Date: 7/24/2008 10:22:31 AM
*/
SET FOREIGN_KEY_CHECKS=0;
--
-- Table structure for test_table
--
CREATE TABLE `test_table` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` binary(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
--
-- Records
--
INSERT INTO `test_table` VALUES ('1', 'A');
[2008-07-24 14:20:36] djneoform at gmail dot com
Results:
TEST STRING LENGTH: 51
RETURNED STRING LENGTH: 100
[2008-07-24 14:19:36] djneoform at gmail dot com
http://phpneoform.com/error.php
Here's this script running on a win2k3 server with PHP 5.2.6 and mysql
5.0.62
query("DROP TABLE IF EXISTS `test_table`");
$mysqli->query("
CREATE TABLE `test_table` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` binary(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
");
$str = str_repeat('A', 25).chr(0x0).str_repeat('B', 25);
echo "TEST STRING LENGTH: ".strlen($str)."\n";
$mysqli->query("
INSERT INTO
`test_table`
SET
`name` = '".$mysqli->real_escape_string($str)."'
");
$id = $mysqli->insert_id;
$result = $mysqli->query("
SELECT
name
FROM
`test_table`
WHERE
id = '".intval($id)."'
");
$result = $result->fetch_object();
echo "RETURNED STRING LENGTH: ".strlen($result->name)."\n";
?>
[2008-07-24 13:37:53] [EMAIL PROTECTED]
Hi,
Do you still experience it?
Can you reproduce it with a simple script?
Can you provide a dump or just the data, index + frm, considering you
are using MyISAM?
[2008-07-14 18:16:27] djneoform at gmail dot com
I was using v.5.0.51b 64bit (win2k3) at the time.
Right now I'm using a compiled version of the enterprise code, 5.0.62
from apachelounge.com.
When I do an insert a value:
mysqli_real_escape_string('foo'.chr(0x0).'bar')
all i see in the table after is "foo"
maybe this is a windows only issue?
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/44998
--
Edit this bug report at http://bugs.php.net/?id=44998&edit=1
#45484 [Opn]: PDOStatment set datatype to string
ID: 45484
Updated by: [EMAIL PROTECTED]
Reported By: cbidon007 at hotmail dot com
Status: Open
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5.2.6
New Comment:
The string conversion is not a bug in the driver. Its how PDO has been
designed. FETCH:ASSOC will always perform a string conversion regardless
of the driver. Use bindColumn():
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0);
$stmt = $db->query("SELECT 1");
$stmt->bindColumn(1, $value, PDO::PARAM_INT);
$stmt->fetch(PDO::FETCH_BOUND)
Not respected locale setting might be a bug. Check again using
bindColumn().
Previous Comments:
[2008-07-11 11:03:57] cbidon007 at hotmail dot com
Description:
Hy,
I use an oracle database and my locale setting for the decimal point is
",".
When I run a SELECT query with a float datatype column, the result is a
string datatype value and the decimal separator is ','.
And PHP don't recognize this as a number.
Why oracle column datatypes are not kept?
Reproduce code:
---
$oPDOStmt = $oConn->query("SELECT 12.34 AS NB FROM DUAL");
$arrResult = $oPDOStmt->fetch(PDO::FETCH_ASSOC);
print_r($arrResult);
print gettype($arrResult["NB"]);
Expected result:
Array
(
[NB] => 12.34
)
Actual result:
--
Array
(
[NB] => 12,34
)
--
Edit this bug report at http://bugs.php.net/?id=45484&edit=1
#22624 [Com]: Mulitple PHP processes launched using 100% CPU
ID: 22624 Comment by: fhggfj at hg dot fd Reported By: webmaster at enterzone dot com Status: No Feedback Bug Type: Performance problem Operating System: WinNT4 PHP Version: 4.3.1 New Comment: http://www.forex.co.ir forex Ùارکس Ø¢Ù Ùزش Ùارکس Previous Comments: [2003-03-15 18:47:40] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-03-10 12:25:17] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. A reproduce script is needed, and if it is more then 10 lines, please put a link here to it. [2003-03-10 11:57:58] webmaster at enterzone dot com WinNT 4 SP6a, all of the latest patches (yea, yea I know). PHP 4.3.1 I am getting 1,2,4, or more process instances of PHP running using 100% CPU. Cannot narrow it down to bad programming code by users or a php.exe problem. Most PHP is running fine. I have a few PHP forums running. I cannot reproduce the problem, but it is increasing. Concerned that it may be a attack. This is now occurring 4 or more times a day. Only option is to kill the errant processes. Sometimes a reboot of the server is mandatory. After killing the processes, normal PHP code in our forums runs fine. There are not any consistent instances of PHP runing in the background unless this problem reoccurs. The PHP.INI is set as follows; max_execution_tim = 30; max_imput_time = 60; memory_limit = 8M . It has now effect on this problem, we have seen it run over 4 hours without a sign of stopping on its own. I don't have the memory usage noted, there is not any unusually high traffic across our network during the instance. Most dynamic pages fail, only static pages are served from IIS, due to the high CPU load. PHP request run, but very slowly as do all request during this time. -- Edit this bug report at http://bugs.php.net/?id=22624&edit=1
#45721 [NEW]: TOC overflow on IBM AIX ld
From: Bjorn dot Wiberg at its dot uu dot se
Operating system: IBM AIX 5.3 5300-08-01-0819
PHP version: 5.3.0alpha1
PHP Bug Type: Compile Failure
Bug description: TOC overflow on IBM AIX ld
Description:
When compiling on AIX, one gets a TOC overflow error from ld.
Something like:
export LDFLAGS="-Wl,-bbigtoc" (if using gcc) or
export LDFLAGS="-bbigtoc" (if using cc/xlC)
...prior to running ./configure (and make) appears to be needed.
This was not the case with PHP 5.2.6.
Reproduce code:
---
#! /bin/sh
#
# Created by configure
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
No TOC overflow error. Successful linking.
Actual result:
--
---8<--- excerpt ---8<---
GNOME_ACL/GNOME/build/acc_gnome2_12_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_12_0/export/power_510_32/usr/lib
-lX11 -lXpm -lpng
-L/gestconf/project/GNOME_ACL/GNOME/build/BLD_M_gnome2_14f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/M_acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_14_0/export/power_510_32/usr/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/ccs/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/lib -lz -ljpeg -lssl -lcrypto
-lgdbm -lbz2 -lz -lssl -lcrypto -lm -lz -liconv -lm -lcurl -lssl -lcrypto
-lz -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz
-liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lxslt -lxml2
-lz -liconv -lm -lc -Wl,-brtl -Wl,-bI:/apache/modules/httpd.exp
-Wl,-bE:.libs/libphp5.exp -Wl,-bnoentry ${wl}-berok
ld: 0711-224 WARNING: Duplicate symbol: php_optidx
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-781 ERROR: TOC overflow. TOC size: 72448 Maximum size:
65536
collect2: ld returned 12 exit status
make: *** [libphp5.la] Error 1
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.22146 (%build)
---8<--- end excerpt --8<--
--
Edit bug report at http://bugs.php.net/?id=45721&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45721&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45721&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45721&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45721&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45721&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45721&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45721&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45721&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45721&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45721&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45721&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45721&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45721&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45721&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45721&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45721&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45721&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45721&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45721&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45721&r=mysqlcfg
#45712 [Opn->Ctl]: $something == NaN returns true with 5.3, false with 5.2.*
ID: 45712 Updated by: [EMAIL PROTECTED] -Summary: $something == NaN returns true with PHP 5.3.0, which returns false until 5.2.6 Reported By: for-bugs at hnw dot jp -Status: Open +Status: Critical Bug Type: Variables related -Operating System: MacOSX +Operating System: * PHP Version: 5.3.0alpha1 Previous Comments: [2008-08-05 02:39:58] for-bugs at hnw dot jp Description: There is == operator's problem dealing with NaN(Not a Number) in PHP 5.3.0alpha1. This behavior is different with PHP 5.0.0-5.2.6, so this is compatibility problem. Reproduce code: --- http://bugs.php.net/?id=45712&edit=1
#45718 [Opn->Bgs]: h
ID: 45718 Updated by: [EMAIL PROTECTED] Reported By: h at h dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: h PHP Version: 4.4.8 New Comment: g Previous Comments: [2008-08-05 09:44:10] h at h dot com Description: h Reproduce code: --- h Expected result: h -- Edit this bug report at http://bugs.php.net/?id=45718&edit=1
#45715 [Opn->Bgs]: CPU utilization goes high of application server and not the mysql server
ID: 45715
Updated by: [EMAIL PROTECTED]
Reported By: lavesh dot rawat at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2CVS-2008-08-05 (CVS)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-08-05 07:24:33] lavesh dot rawat at gmail dot com
Description:
popen commnads uses cpu of application server rather than database
server.
when I run command popen("php -q filename.php");
where filename.php have some query whose database connection goes to
some other database.
CPU Utilization of current server server goes high istead of mysql
server.
Expected result:
CPU Utilization of current server server should not be much affected as
queries are running on mysql server which is normally the case when we
run queries.
--
Edit this bug report at http://bugs.php.net/?id=45715&edit=1
#45613 [Com]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Comment by: crocodile2u at yandex dot ru Reported By: crocodile2u at yandex dot ru Status: No Feedback Bug Type: Apache2 related Operating System: Ununtu 8.04 PHP Version: 5.3CVS-2008-07-24 (CVS) New Comment: The problem is still here with PHP-5.3.0alpha Previous Comments: [2008-08-01 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-07-24 08:02:44] crocodile2u at yandex dot ru Description: Get a segfault when using is_file() in a web-server environment (Apache/2.2.8 (Ubuntu) PHP/5.3.0-dev). Seems to be web-server related as CLI version works as expected. Reproduce code: --- http://bugs.php.net/?id=45613&edit=1
#45722 [NEW]: Segmentation fault
From: estacuentanolamiro at gmail dot com
Operating system: Ubuntu 6.06 LTS server
PHP version: 5.2.6
PHP Bug Type: mbstring related
Bug description: Segmentation fault
Description:
mb_check_encoding segmentation fault
Reproduce code:
---
$text = "&· ASDF ASDF ASDF ASDF ASDF ASDF ASDF";
if( mb_check_encoding($text,'HTML-ENTITIES') ) {
$text = htmlentities($text);
}
echo $text;
Expected result:
string
Actual result:
--
Nothing, segmentation fault.
--
Edit bug report at http://bugs.php.net/?id=45722&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45722&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45722&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45722&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45722&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45722&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45722&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45722&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45722&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45722&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45722&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45722&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45722&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45722&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45722&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45722&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45722&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45722&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45722&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45722&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45722&r=mysqlcfg
#45721 [Opn->Bgs]: TOC overflow on IBM AIX ld
ID: 45721
Updated by: [EMAIL PROTECTED]
Reported By: Bjorn dot Wiberg at its dot uu dot se
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: IBM AIX 5.3 5300-08-01-0819
PHP Version: 5.3.0alpha1
New Comment:
Expected behaviour. Just use those flags.
Previous Comments:
[2008-08-05 11:42:37] Bjorn dot Wiberg at its dot uu dot se
Description:
When compiling on AIX, one gets a TOC overflow error from ld.
Something like:
export LDFLAGS="-Wl,-bbigtoc" (if using gcc) or
export LDFLAGS="-bbigtoc" (if using cc/xlC)
...prior to running ./configure (and make) appears to be needed.
This was not the case with PHP 5.2.6.
Reproduce code:
---
#! /bin/sh
#
# Created by configure
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
No TOC overflow error. Successful linking.
Actual result:
--
---8<--- excerpt ---8<---
GNOME_ACL/GNOME/build/acc_gnome2_12_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_12_0/export/power_510_32/usr/lib
-lX11 -lXpm -lpng
-L/gestconf/project/GNOME_ACL/GNOME/build/BLD_M_gnome2_14f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/M_acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_14_0/export/power_510_32/usr/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/ccs/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/lib -lz -ljpeg -lssl -lcrypto
-lgdbm -lbz2 -lz -lssl -lcrypto -lm -lz -liconv -lm -lcurl -lssl
-lcrypto -lz -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv
-lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm
-lxslt -lxml2 -lz -liconv -lm -lc -Wl,-brtl
-Wl,-bI:/apache/modules/httpd.exp -Wl,-bE:.libs/libphp5.exp
-Wl,-bnoentry ${wl}-berok
ld: 0711-224 WARNING: Duplicate symbol: php_optidx
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-781 ERROR: TOC overflow. TOC size: 72448 Maximum size:
65536
collect2: ld returned 12 exit status
make: *** [libphp5.la] Error 1
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.22146 (%build)
---8<--- end excerpt --8<--
--
Edit this bug report at http://bugs.php.net/?id=45721&edit=1
#45722 [Opn]: Segmentation fault
ID: 45722
User updated by: estacuentanolamiro at gmail dot com
Reported By: estacuentanolamiro at gmail dot com
Status: Open
Bug Type: mbstring related
Operating System: Ubuntu 6.06 LTS server
PHP Version: 5.2.6
New Comment:
Sorry, correct reproduce code:
$text = "&· ASDF ASDF ASDF ASDF ASDF ASDF ASDF";
if( !mb_check_encoding($text,'HTML-ENTITIES') ) {
$text = htmlentities($text);
}
echo $text;
Previous Comments:
[2008-08-05 11:51:30] estacuentanolamiro at gmail dot com
Description:
mb_check_encoding segmentation fault
Reproduce code:
---
$text = "&· ASDF ASDF ASDF ASDF ASDF ASDF ASDF";
if( mb_check_encoding($text,'HTML-ENTITIES') ) {
$text = htmlentities($text);
}
echo $text;
Expected result:
string
Actual result:
--
Nothing, segmentation fault.
--
Edit this bug report at http://bugs.php.net/?id=45722&edit=1
#45721 [Bgs]: TOC overflow on IBM AIX ld
ID: 45721
User updated by: Bjorn dot Wiberg at its dot uu dot se
Reported By: Bjorn dot Wiberg at its dot uu dot se
Status: Bogus
Bug Type: Compile Failure
Operating System: IBM AIX 5.3 5300-08-01-0819
PHP Version: 5.3.0alpha1
New Comment:
Shouldn't ./configure take care of this if detecting AIX? Especially if
this has occurred with PHP 5.3 and up?
Previous Comments:
[2008-08-05 11:53:08] [EMAIL PROTECTED]
Expected behaviour. Just use those flags.
[2008-08-05 11:42:37] Bjorn dot Wiberg at its dot uu dot se
Description:
When compiling on AIX, one gets a TOC overflow error from ld.
Something like:
export LDFLAGS="-Wl,-bbigtoc" (if using gcc) or
export LDFLAGS="-bbigtoc" (if using cc/xlC)
...prior to running ./configure (and make) appears to be needed.
This was not the case with PHP 5.2.6.
Reproduce code:
---
#! /bin/sh
#
# Created by configure
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
No TOC overflow error. Successful linking.
Actual result:
--
---8<--- excerpt ---8<---
GNOME_ACL/GNOME/build/acc_gnome2_12_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_12_0/export/power_510_32/usr/lib
-lX11 -lXpm -lpng
-L/gestconf/project/GNOME_ACL/GNOME/build/BLD_M_gnome2_14f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/M_acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_14_0/export/power_510_32/usr/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/ccs/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/lib -lz -ljpeg -lssl -lcrypto
-lgdbm -lbz2 -lz -lssl -lcrypto -lm -lz -liconv -lm -lcurl -lssl
-lcrypto -lz -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv
-lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm
-lxslt -lxml2 -lz -liconv -lm -lc -Wl,-brtl
-Wl,-bI:/apache/modules/httpd.exp -Wl,-bE:.libs/libphp5.exp
-Wl,-bnoentry ${wl}-berok
ld: 0711-224 WARNING: Duplicate symbol: php_optidx
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-781 ERROR: TOC overflow. TOC size: 72448 Maximum size:
65536
collect2: ld returned 12 exit status
make: *** [libphp5.la] Error 1
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.22146 (%build)
---8<--- end excerpt --8<--
--
Edit this bug report at http://bugs.php.net/?id=45721&edit=1
#45723 [NEW]: 'siginfo_t' has no member named 'si_fd' compilation error
From: Bjorn dot Wiberg at its dot uu dot se Operating system: IBM AIX 5.3 5300-08-01-0819 PHP version: 5.3.0alpha1 PHP Bug Type: Compile Failure Bug description: 'siginfo_t' has no member named 'si_fd' compilation error Description: Enabling pcntl on IBM AIX yields error "'siginfo_t' has no member named 'si_fd'". Reproduce code: --- #! /bin/sh # # Created by configure LDFLAGS='-Wl,-bbigtoc' \ CC='gcc' \ './configure' \ '--disable-fileinfo' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Expected result: Successful compilation. Actual result: -- ---8<---8<--- gcc -Iext/pcntl/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c -DPIC -o ext/pcntl/.libs/pcntl.o /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:180: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:197: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'php_register_signal_constants': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:351: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_activate_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:363: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_startup_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:371: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_shutdown_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:376: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_deactivate_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:396: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_info_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:403: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_fork': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:417: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_alarm': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:430: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_waitpid': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:454: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_wait': /home/bwiberg/rpm/
#45722 [Opn->Asn]: mb_check_encoding() crashes
ID: 45722
Updated by: [EMAIL PROTECTED]
Reported By: estacuentanolamiro at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: mbstring related
Operating System: *
PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-05)
-Assigned To:
+Assigned To: moriyoshi
New Comment:
Moriyoshi, verified with all branches.
Previous Comments:
[2008-08-05 11:54:36] estacuentanolamiro at gmail dot com
Sorry, correct reproduce code:
$text = "&· ASDF ASDF ASDF ASDF ASDF ASDF ASDF";
if( !mb_check_encoding($text,'HTML-ENTITIES') ) {
$text = htmlentities($text);
}
echo $text;
[2008-08-05 11:51:30] estacuentanolamiro at gmail dot com
Description:
mb_check_encoding segmentation fault
Reproduce code:
---
$text = "&· ASDF ASDF ASDF ASDF ASDF ASDF ASDF";
if( mb_check_encoding($text,'HTML-ENTITIES') ) {
$text = htmlentities($text);
}
echo $text;
Expected result:
string
Actual result:
--
Nothing, segmentation fault.
--
Edit this bug report at http://bugs.php.net/?id=45722&edit=1
#45723 [Opn->Fbk]: 'siginfo_t' has no member named 'si_fd' compilation error
ID: 45723 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: IBM AIX 5.3 5300-08-01-0819 PHP Version: 5.3.0alpha1 New Comment: Does ANYTHING work on that antique OS? Feel free to provide patches. You're propably the only person using AIX and PHP.. Previous Comments: [2008-08-05 11:59:53] Bjorn dot Wiberg at its dot uu dot se Description: Enabling pcntl on IBM AIX yields error "'siginfo_t' has no member named 'si_fd'". Reproduce code: --- #! /bin/sh # # Created by configure LDFLAGS='-Wl,-bbigtoc' \ CC='gcc' \ './configure' \ '--disable-fileinfo' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Expected result: Successful compilation. Actual result: -- ---8<---8<--- gcc -Iext/pcntl/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/ -DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex -I/usr/local/include/libxml2 -I/opt/freeware/include -I/usr/local/include -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib -I/usr/X11R6/include -I/usr/include/freetype2 -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g -fvisibility=hidden -O0 -Wall -c /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c -DPIC -o ext/pcntl/.libs/pcntl.o /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:180: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:197: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'php_register_signal_constants': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:351: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_activate_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:363: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_startup_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:371: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_shutdown_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:376: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_deactivate_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:396: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zm_info_pcntl': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:403: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_fork': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:417: warning: visibility attribute not supported in this configuration; ignored /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function 'zif_pcntl_alarm': /home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:430: warning: visibility attribute not supported in this configuration; ignored /hom
#36398 [Com]: "make test" should be fully scriptable [Do not prompt for email address]
ID: 36398
Comment by: Bjorn dot Wiberg at its dot uu dot se
Reported By: nickj-phpbugs at nickj dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Shouldn't the patch be incorporated into run-tests.php? As it has been
around for a long time.
Previous Comments:
[2006-02-17 06:53:53] nickj-phpbugs at nickj dot org
No worries! There is a patch now available for this at:
http://www.files.nickj.org/php/run-tests-patch.txt
Also, the run-test.php script is not currently E_STRICT clean. I have
included in the patch some simple changes I had to make to get it to run
with E_STRICT enabled.
Note that there are 3 remaining things I did not know how to fix for
clean E_STRICT output, so even with this patch run-tests.php is still
not totally E_STRICT clean. The three remaining things were:
1) Was this error:
Error! type: 8; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 93; Message:
ob_end_clean(): failed to delete buffer. No buffer to delete.
... which was generated by this line under E_STRICT:
while(@ob_end_clean());
2) Was the use of date() in this line:
$output_file = $CUR_DIR . '/php_test_results_' . date('Ymd_Hi') .
'.txt';
Which gives this error under E_STRICT:
Error! type: 2048; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 246; Message:
date(): It is not safe to rely on the system's timezone settings. Please
use the date.timezone setting, the TZ environment variable or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Australia/Melbourne'
for 'EST/11.0/DST' instead
Not sure how to say "just use the system default" nowadays, given that
we probably shouldn't hard-code a timezone, as users from anywhere could
be running this test script.
3) Was the "select_stream" call in the "system_with_timeout" function,
which generates this error under E_STRICT:
Error! type: 2; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 893; Message:
stream_select(): 230 is not a valid stream resource
[2006-02-16 07:35:06] [EMAIL PROTECTED]
Thanks, I've just fixed the typo.
As for the request - I'm pretty sure you can add it to run-tests.php
and send a patch for us to review.
Though, I don't know if we really want php-qa list to get filled with
results of the tests executed automatically every X minutes.
[2006-02-16 06:19:59] nickj-phpbugs at nickj dot org
Thank you - that sort of helps, and I realise now that I should have
phrased my request better (so I have reopened, and rephrased it to
hopefully be clearer).
What I mostly wanted was to run the tests, and then email the results
off, without prompting.
I can enable/disable the prompt now with:
TEST_PHP_ARGS="-q" make test
And I can see the available options with:
TEST_PHP_EXECUTABLE="/root/tmp/php-5.1-dev/php5.1-200602150330/sapi/cli/php"
sapi/cli/php run-tests.php --help
However, unless I am mistaken, I can't see any option to specify the
email address to use, such as for example:
TEST_PHP_ARGS="--email-results [EMAIL PROTECTED]" make test
My underlying assumption here is that you folks want and use the output
of "make test" in some way. If that's not the case, then of course,
don't make it an option. However, if you are using this, then wouldn't
it be good to be able to script it so that it could automatically email
off the results of make test, without having to prompt the user? Then
you could (for example) have the build farm automatically email the
qa.php.net list with the results of "make test" after every build of
every snapshot. Maybe you already do this in some other way, but if not,
it seems like it could be useful to me.
You could also update http://qa.php.net/running-tests.php with this
information, so that people could "set and forget" to run the tests and
email the results, without prompting them.
P.s. there is a very small typo in the help for "make test". It says
"-q Quite, no user interaction"; but you want it to say "Quiet", not
"Quite".
[2006-02-15 08:48:46] [EMAIL PROTECTED]
You can already do this, set the env variable TEST_PHP_ARGS to "-q" and
it should skip the question. Use -h to get all available options.
[2006-02-15 06:56:06] nickj-phpbugs at nickj dot org
Description:
I have a little shell script to download PHP snapshots, extract them,
configure them, and build them. I would like to add automatically
running "make test" on them.
However, it does not appear
#45724 [NEW]: correct "new Object()->method()"
From: bastard_man at hotmail dot co dot uk
Operating system: XP/Ubuntu
PHP version: 5.3CVS-2008-08-05 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: correct "new Object()->method()"
Description:
Hello,
can you help me with a feature change in PHP?
in java this code works well
AClass object = new AClass().aMethod();
in php it doesnt.
It is possible to correct this so the syntax is valid?
Reproduce code:
---
class AClass
{
public function __construct()
{echo("a"); /* return $this; */ }
public function method1()
{echo("b"); return $this;}
public function method2()
{echo("c"); return $this;}
public static main()
{$obj = new TestPhp()->method1()->method2();}
}
AClass::main();
Expected result:
abc
Actual result:
--
(Fatal Error)
--
Edit bug report at http://bugs.php.net/?id=45724&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45724&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45724&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45724&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45724&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45724&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45724&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45724&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45724&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45724&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45724&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45724&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45724&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45724&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45724&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45724&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45724&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45724&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45724&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45724&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45724&r=mysqlcfg
#45712 [Ctl]: $something == NaN returns true with 5.3, false with 5.2.*
ID: 45712 Updated by: [EMAIL PROTECTED] Reported By: for-bugs at hnw dot jp Status: Critical Bug Type: Variables related Operating System: * -PHP Version: 5.3.0alpha1 +PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-05) New Comment: That $nan == $nan should be true. (like it is with 5.3) Previous Comments: [2008-08-05 02:39:58] for-bugs at hnw dot jp Description: There is == operator's problem dealing with NaN(Not a Number) in PHP 5.3.0alpha1. This behavior is different with PHP 5.0.0-5.2.6, so this is compatibility problem. Reproduce code: --- http://bugs.php.net/?id=45712&edit=1
#45712 [Ctl]: $something == NaN returns true with 5.3, false with 5.2.*
ID: 45712
User updated by: for-bugs at hnw dot jp
Reported By: for-bugs at hnw dot jp
Status: Critical
Bug Type: Variables related
Operating System: *
PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-05)
New Comment:
NaN is not exact number. So, NaN should not equals itself. Additionaly,
NaN == NaN is false in C. You can see behavior of C as follows.
$ cat nan.c
int main() {double d;d=(-1e300*1e300)/(1e300*1e300);if (d==d) return 1;
else return 2;}
$ gcc nan.c; ./a.out; echo $?
2
$
Previous Comments:
[2008-08-05 12:33:17] [EMAIL PROTECTED]
That $nan == $nan should be true. (like it is with 5.3)
[2008-08-05 02:39:58] for-bugs at hnw dot jp
Description:
There is == operator's problem dealing with NaN(Not a Number) in PHP
5.3.0alpha1. This behavior is different with PHP 5.0.0-5.2.6, so this is
compatibility problem.
Reproduce code:
---
http://bugs.php.net/?id=45712&edit=1
#45725 [NEW]: date_create DateTime format('z') returns null
From: john dot oconnor at landingnet dot co dot uk
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: Date/time related
Bug description: date_create DateTime format('z') returns null
Description:
When using date_create to find out the day of the year for a given date
using the date string format 'z', you expect a result from 0-365.
When testing 2008-01-02 you get the expected result 1.
With 2008-01-01 the format returns null, incorrectly.
Reproduce code:
---
$date_time = date_create('2008-01-01 00:00:00');
$formatted_time = $date_time->format('z');
var_dump($formatted_time);
Expected result:
integer of value zero.
Actual result:
--
null
--
Edit bug report at http://bugs.php.net/?id=45725&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45725&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45725&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45725&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45725&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45725&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45725&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45725&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45725&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45725&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45725&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45725&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45725&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45725&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45725&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45725&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45725&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45725&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45725&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45725&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45725&r=mysqlcfg
#45725 [Opn->Csd]: date_create DateTime format('z') returns null
ID: 45725
User updated by: john dot oconnor at landingnet dot co dot uk
Reported By: john dot oconnor at landingnet dot co dot uk
-Status: Open
+Status: Closed
Bug Type: Date/time related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
submitted in error
Previous Comments:
[2008-08-05 12:53:44] john dot oconnor at landingnet dot co dot uk
Description:
When using date_create to find out the day of the year for a given date
using the date string format 'z', you expect a result from 0-365.
When testing 2008-01-02 you get the expected result 1.
With 2008-01-01 the format returns null, incorrectly.
Reproduce code:
---
$date_time = date_create('2008-01-01 00:00:00');
$formatted_time = $date_time->format('z');
var_dump($formatted_time);
Expected result:
integer of value zero.
Actual result:
--
null
--
Edit this bug report at http://bugs.php.net/?id=45725&edit=1
#45723 [Fbk->Opn]: 'siginfo_t' has no member named 'si_fd' compilation error
ID: 45723
User updated by: Bjorn dot Wiberg at its dot uu dot se
Reported By: Bjorn dot Wiberg at its dot uu dot se
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: IBM AIX 5.3 5300-08-01-0819
PHP Version: 5.3.0alpha1
New Comment:
Attaching patch below. The si_fd member simply does not exist in
siginfo_t on AIX, so skipping it. Couldn't find any more references to
it in the code, nor in any include or sys/include files on the system.
(Also couldn't find any info on pcntl_sigwaitinfo() in the PHP
documentation for pcntl functions -- documentation issue?)
Best regards,
Björn
diff -cr php-5.3.0alpha1/ext/pcntl/pcntl.c
php-5.3.0alpha1-my/ext/pcntl/pcntl.c
*** php-5.3.0alpha1/ext/pcntl/pcntl.c 2008-07-29 18:59:10.0
+0200
--- php-5.3.0alpha1-my/ext/pcntl/pcntl.c2008-08-05
15:23:48.0 +0200
***
*** 883,889
--- 883,894
#ifdef SIGPOLL
case SIGPOLL:
add_assoc_long_ex(user_siginfo, "band",
sizeof("band"), siginfo.si_band);
+
+ /* AIX: No si_fd member of siginfo_t in ; see
http://bugs.php.net/bug.php?id=45723 */
+ #ifndef _AIX
add_assoc_long_ex(user_siginfo, "fd",
sizeof("fd"), siginfo.si_fd);
+ #endif
+
break;
#endif
EMPTY_SWITCH_DEFAULT_CASE();
Previous Comments:
[2008-08-05 12:13:55] [EMAIL PROTECTED]
Does ANYTHING work on that antique OS? Feel free to provide patches.
You're propably the only person using AIX and PHP..
[2008-08-05 11:59:53] Bjorn dot Wiberg at its dot uu dot se
Description:
Enabling pcntl on IBM AIX yields error "'siginfo_t' has no member named
'si_fd'".
Reproduce code:
---
#! /bin/sh
#
# Created by configure
LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
Successful compilation.
Actual result:
--
---8<---8<---
gcc -Iext/pcntl/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/
-DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/usr/local/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib
-I/usr/X11R6/include -I/usr/include/freetype2
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g
-fvisibility=hidden -O0 -Wall -c
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c -DPIC -o
ext/pcntl/.libs/pcntl.o
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:180: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:197: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function
'php_register_signal_constants':
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:351: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function
'zm_activate_pcntl':
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:363: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function
'zm_startup_pcntl':
/home/bwiberg/rpm/BUI
#45723 [Opn]: 'siginfo_t' has no member named 'si_fd' compilation error
ID: 45723
Updated by: [EMAIL PROTECTED]
Reported By: Bjorn dot Wiberg at its dot uu dot se
Status: Open
Bug Type: Compile Failure
Operating System: IBM AIX 5.3 5300-08-01-0819
PHP Version: 5.3.0alpha1
New Comment:
New stuff. Actually this should be tested during configure.
Previous Comments:
[2008-08-05 13:45:52] Bjorn dot Wiberg at its dot uu dot se
Attaching patch below. The si_fd member simply does not exist in
siginfo_t on AIX, so skipping it. Couldn't find any more references to
it in the code, nor in any include or sys/include files on the system.
(Also couldn't find any info on pcntl_sigwaitinfo() in the PHP
documentation for pcntl functions -- documentation issue?)
Best regards,
Björn
diff -cr php-5.3.0alpha1/ext/pcntl/pcntl.c
php-5.3.0alpha1-my/ext/pcntl/pcntl.c
*** php-5.3.0alpha1/ext/pcntl/pcntl.c 2008-07-29 18:59:10.0
+0200
--- php-5.3.0alpha1-my/ext/pcntl/pcntl.c2008-08-05
15:23:48.0 +0200
***
*** 883,889
--- 883,894
#ifdef SIGPOLL
case SIGPOLL:
add_assoc_long_ex(user_siginfo, "band",
sizeof("band"), siginfo.si_band);
+
+ /* AIX: No si_fd member of siginfo_t in ; see
http://bugs.php.net/bug.php?id=45723 */
+ #ifndef _AIX
add_assoc_long_ex(user_siginfo, "fd",
sizeof("fd"), siginfo.si_fd);
+ #endif
+
break;
#endif
EMPTY_SWITCH_DEFAULT_CASE();
[2008-08-05 12:13:55] [EMAIL PROTECTED]
Does ANYTHING work on that antique OS? Feel free to provide patches.
You're propably the only person using AIX and PHP..
[2008-08-05 11:59:53] Bjorn dot Wiberg at its dot uu dot se
Description:
Enabling pcntl on IBM AIX yields error "'siginfo_t' has no member named
'si_fd'".
Reproduce code:
---
#! /bin/sh
#
# Created by configure
LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
Successful compilation.
Actual result:
--
---8<---8<---
gcc -Iext/pcntl/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/
-DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/usr/local/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib
-I/usr/X11R6/include -I/usr/include/freetype2
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g
-fvisibility=hidden -O0 -Wall -c
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c -DPIC -o
ext/pcntl/.libs/pcntl.o
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:180: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:197: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function
'php_register_signal_constants':
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:351: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c: In function
'zm_activate_pcntl':
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:363: warning:
visibility attribute not suppo
#45726 [NEW]: PHP_Archive / Archive.php missing
From: Bjorn dot Wiberg at its dot uu dot se Operating system: IBM AIX 5.3 5300-08-01-0819 PHP version: 5.3.0alpha1 PHP Bug Type: Compile Failure Bug description: PHP_Archive / Archive.php missing Description: PHP complains about Archive.php / PHP_Archive not being found during compilation. Reproduce code: --- #! /bin/sh # # Created by configure LDFLAGS='-Wl,-bbigtoc' \ CC='gcc' \ './configure' \ '--disable-fileinfo' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Followed by '/opt/freeware/bin/make' (GNU make). Expected result: No error message. Actual result: -- gcc -I/usr/include -g -fvisibility=hidden -O0 -Wall -Wl,-bbigtoc -Wl,-brtl -Wl,-bE:php.sym ext/ereg/.libs/ereg.o ext/ereg/regex/.libs/regcomp.o ext/ereg/regex/.libs/regexec.o ext/ereg/regex/.libs/regerror.o ext/ereg/regex/.libs/regfree.o ext/libxml/.libs/libxml.o ext/openssl/.libs/openssl.o ext/openssl/.libs/xp_ssl.o ext/pcre/pcrelib/.libs/pcre_chartables.o ext/pcre/pcrelib/.libs/pcre_ucp_searchfuncs.o ext/pcre/pcrelib/.libs/pcre_compile.o ext/pcre/pcrelib/.libs/pcre_config.o ext/pcre/pcrelib/.libs/pcre_exec.o ext/pcre/pcrelib/.libs/pcre_fullinfo.o ext/pcre/pcrelib/.libs/pcre_get.o ext/pcre/pcrelib/.libs/pcre_globals.o ext/pcre/pcrelib/.libs/pcre_info.o ext/pcre/pcrelib/.libs/pcre_maketables.o ext/pcre/pcrelib/.libs/pcre_newline.o ext/pcre/pcrelib/.libs/pcre_ord2utf8.o ext/pcre/pcrelib/.libs/pcre_refcount.o ext/pcre/pcrelib/.libs/pcre_study.o ext/pcre/pcrelib/.libs/pcre_tables.o ext/pcre/pcrelib/.libs/pcre_try_flipped.o ext/pcre/pcrelib/.libs/pcre_valid_utf8.o ext/pcre/pcrelib/.libs/pcre_version.o ext/pcre/pcrelib/.libs/pcre_xclass.o ext/pcre/.libs/php_pcre.o ext/zlib/.libs/zlib.o ext/zlib/.libs/zlib_fopen_wrapper.o ext/zlib/.libs/zlib_filter.o ext/bcmath/.libs/bcmath.o ext/bcmath/libbcmath/src/.libs/add.o ext/bcmath/libbcmath/src/.libs/div.o ext/bcmath/libbcmath/src/.libs/init.o ext/bcmath/libbcmath/src/.libs/neg.o ext/bcmath/libbcmath/src/.libs/outofmem.o ext/bcmath/libbcmath/src/.libs/raisemod.o ext/bcmath/libbcmath/src/.libs/rt.o ext/bcmath/libbcmath/src/.libs/sub.o ext/bcmath/libbcmath/src/.libs/compare.o ext/bcmath/libbcmath/src/.libs/divmod.o ext/bcmath/libbcmath/src/.libs/int2num.o ext/bcmath/libbcmath/src/.libs/num2long.o ext/bcmath/libbcmath/src/.libs/output.o ext/bcmath/libbcmath/src/.libs/recmul.o ext/bcmath/libbcmath/src/.libs/sqrt.o ext/bcmath/libbcmath/src/.libs/zero.o ext/bcmath/libbcmath/src/.libs/debug.o ext/bcmath/libbcmath/src/.libs/doaddsub.o ext/bcmath/libbcmath/src/.libs/nearzero.o ext/bcmath/libbcmath/src/.libs/num2str.o ext/bcmath/libbcmath/src/.libs/raise.o ext/bcmath/libbcmath/src/.libs/rmzero.o ext/bcmath/libbcmath/src/.libs/str2num.o ext/bz2/.libs/bz2.o ext/bz2/.libs/bz2_filter.o ext/calendar/.libs/calendar.o ext/calendar/.libs/dow.o ext/calendar/.libs/french.o ext/calendar/.libs/gregor.o ext/calendar/.libs/jewish.o ext/calendar/.libs/julian.o ext/calendar/.libs/easter.o ext/calendar/.libs/cal_unix.o ext/ctype/.libs/ctype.o ext/curl/.libs/interface.o ext/curl/.libs/multi.o ext/curl/.libs/streams.o ext/date/.libs/php_date.o ext/date/lib/.libs/astro.o ext/date/lib/.libs/dow.o ext/date/lib/.libs/parse_date.o ext/date/lib/.libs/parse_tz.o ext/date/lib/.libs/timelib.o ext/date/lib/.libs/tm2unixtime.o ext/date/lib/.libs/unixtime2tm.o ext/date/lib/.libs/parse_iso_intervals.o ext/date/lib/.libs/interval.o ext/dba/.libs/dba.o ext/dba/.libs/dba_cdb.o ext/dba/.libs/dba_dbm.o ext/dba/.libs/dba_gdbm.o ext/dba/.libs/dba_ndbm.o ext/dba/.libs/dba_db1.o ext/dba/.libs/dba_db2.o ext/dba/.libs/dba_db3.o ext/dba/.libs/dba_db4.o ext/dba/.libs/dba_flatfile.o ext/dba/.libs/dba_inifile.o ext/dba/.libs/dba_qdbm.o ext/dba/libcdb/.libs/cdb.o ext/dba/libcdb/.libs/cdb_make.o ext/dba/libcdb/.libs/uint32.o ext/dba/libflatfile/.libs/flatfile.o ext/dba/libinifile/.libs/inifile.o ext/dbase/.libs/dbf_head.o ext/dbase/.libs/dbf_rec.o ext/dbase/.libs/dbf_misc.o ext/dbase/.libs/dbf_ndx.o ext/dbase/.libs/dbase.o ext/dom/.libs/php_dom.o ext/dom/.libs/attr
#45702 [Fbk->Csd]: PDO_SQLITE need to be updated (REQUEST)
ID: 45702 User updated by: syncer at gmail dot com Reported By: syncer at gmail dot com -Status: Feedback +Status: Closed Bug Type: PDO related Operating System: All PHP Version: 5.3.0alpha1 New Comment: Okay, I will give it a try. Thanks Previous Comments: [2008-08-04 14:28:22] [EMAIL PROTECTED] http://sqlite.org/changes.html 3.6.0 is a beta release and we won't bundle that. [2008-08-03 15:43:10] [EMAIL PROTECTED] sqlite3 bundled version uses 3.5.9. pdo-sqlite has modified to use ext/sqlite3 lib as well. Give it a try using 5.3-CVS (or snaps.php.net) [2008-08-03 15:19:02] syncer at gmail dot com Description: Hi, The PDO SQLite driver is forgoten and need to be updated to the current SQLite. Here is some information about the dates and versions: - SQLite PDO Driver version is: 3.1.3 released on 2006-05-01 - Bundled SQLite3 extension: 3.3.9 released on 2008-06-14 - The SQLite current release: 3.6.0 released on 2008-07-16 A lot of pepole were happy after releasing the PDO as a step forward to centralize the database connection, so the question is this dropping support for it, is it DEAD? http://pecl.php.net/package/PDO_SQLITE http://pecl.php.net/package/sqlite3 http://www.sqlite.org/ Cheers, Mina -- Edit this bug report at http://bugs.php.net/?id=45702&edit=1
#45727 [NEW]: DOMDocument::load() is not reporting errors on malformed XML
From: mephtu at yahoo dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: DOM XML related
Bug description: DOMDocument::load() is not reporting errors on malformed XML
Description:
Loading a malformed XML document with DOMDocument::load() fails to report
any errors.
Reproduce code:
---
load.php:
load('malformed.xml');
?>
malformed.xml:
data
Expected result:
I expected to see an error message.
Actual result:
--
Parser dies silently without reporting error.
--
Edit bug report at http://bugs.php.net/?id=45727&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45727&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45727&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45727&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45727&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45727&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45727&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45727&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45727&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45727&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45727&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45727&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45727&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45727&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45727&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45727&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45727&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45727&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45727&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45727&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45727&r=mysqlcfg
#45723 [Opn->Csd]: 'siginfo_t' has no member named 'si_fd' compilation error
ID: 45723
Updated by: [EMAIL PROTECTED]
Reported By: Bjorn dot Wiberg at its dot uu dot se
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: IBM AIX 5.3 5300-08-01-0819
PHP Version: 5.3.0alpha1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-08-05 13:52:55] [EMAIL PROTECTED]
New stuff. Actually this should be tested during configure.
[2008-08-05 13:45:52] Bjorn dot Wiberg at its dot uu dot se
Attaching patch below. The si_fd member simply does not exist in
siginfo_t on AIX, so skipping it. Couldn't find any more references to
it in the code, nor in any include or sys/include files on the system.
(Also couldn't find any info on pcntl_sigwaitinfo() in the PHP
documentation for pcntl functions -- documentation issue?)
Best regards,
Björn
diff -cr php-5.3.0alpha1/ext/pcntl/pcntl.c
php-5.3.0alpha1-my/ext/pcntl/pcntl.c
*** php-5.3.0alpha1/ext/pcntl/pcntl.c 2008-07-29 18:59:10.0
+0200
--- php-5.3.0alpha1-my/ext/pcntl/pcntl.c2008-08-05
15:23:48.0 +0200
***
*** 883,889
--- 883,894
#ifdef SIGPOLL
case SIGPOLL:
add_assoc_long_ex(user_siginfo, "band",
sizeof("band"), siginfo.si_band);
+
+ /* AIX: No si_fd member of siginfo_t in ; see
http://bugs.php.net/bug.php?id=45723 */
+ #ifndef _AIX
add_assoc_long_ex(user_siginfo, "fd",
sizeof("fd"), siginfo.si_fd);
+ #endif
+
break;
#endif
EMPTY_SWITCH_DEFAULT_CASE();
[2008-08-05 12:13:55] [EMAIL PROTECTED]
Does ANYTHING work on that antique OS? Feel free to provide patches.
You're propably the only person using AIX and PHP..
[2008-08-05 11:59:53] Bjorn dot Wiberg at its dot uu dot se
Description:
Enabling pcntl on IBM AIX yields error "'siginfo_t' has no member named
'si_fd'".
Reproduce code:
---
#! /bin/sh
#
# Created by configure
LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Expected result:
Successful compilation.
Actual result:
--
---8<---8<---
gcc -Iext/pcntl/ -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/
-DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/main
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/usr/local/include
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/date/lib
-I/usr/X11R6/include -I/usr/include/freetype2
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/oniguruma
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/mbstring/libmbfl/mbfl
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/sqlite3/libsqlite
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/TSRM
-I/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/Zend -I/usr/include -g
-fvisibility=hidden -O0 -Wall -c
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c -DPIC -o
ext/pcntl/.libs/pcntl.o
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:180: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/pcntl/pcntl.c:197: warning:
visibility attribute not supported in this configuration; ignored
/home/bwiberg/rpm/BUILD/php-5.3.0alpha1/ext/
#45726 [Opn->Fbk]: PHP_Archive / Archive.php missing
ID: 45726 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: IBM AIX 5.3 5300-08-01-0819 PHP Version: 5.3.0alpha1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2008-08-05 13:53:40] Bjorn dot Wiberg at its dot uu dot se Description: PHP complains about Archive.php / PHP_Archive not being found during compilation. Reproduce code: --- #! /bin/sh # # Created by configure LDFLAGS='-Wl,-bbigtoc' \ CC='gcc' \ './configure' \ '--disable-fileinfo' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-cli' \ '--enable-dba' \ '--enable-dbase' \ '--enable-debug' \ '--enable-exif' \ '--enable-flatfile' \ '--enable-ftp' \ '--enable-gd-jis-conv' \ '--enable-gd-native-ttf' \ '--enable-inifile' \ '--enable-mbstring' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sqlite-utf8' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--enable-zip' \ '--enable-zend-multibyte' \ '--prefix=/apache/php' \ '--with-apxs2=/apache/bin/apxs' \ '--with-bz2' \ '--with-cdb' \ '--with-curl' \ '--with-freetype-dir' \ '--with-gd' \ '--with-gdbm' \ '--with-gettext' \ '--with-jpeg-dir' \ '--with-ldap' \ '--with-libxml-dir=/usr/local' \ '--with-mime-magic' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-openssl=/opt/freeware' \ '--with-pdo-mysql=mysqlnd' \ '--with-png-dir' \ '--with-xmlrpc' \ '--with-xpm-dir' \ '--with-xsl' \ '--with-zlib' \ '--with-zlib-dir' \ "$@" Followed by '/opt/freeware/bin/make' (GNU make). Expected result: No error message. Actual result: -- gcc -I/usr/include -g -fvisibility=hidden -O0 -Wall -Wl,-bbigtoc -Wl,-brtl -Wl,-bE:php.sym ext/ereg/.libs/ereg.o ext/ereg/regex/.libs/regcomp.o ext/ereg/regex/.libs/regexec.o ext/ereg/regex/.libs/regerror.o ext/ereg/regex/.libs/regfree.o ext/libxml/.libs/libxml.o ext/openssl/.libs/openssl.o ext/openssl/.libs/xp_ssl.o ext/pcre/pcrelib/.libs/pcre_chartables.o ext/pcre/pcrelib/.libs/pcre_ucp_searchfuncs.o ext/pcre/pcrelib/.libs/pcre_compile.o ext/pcre/pcrelib/.libs/pcre_config.o ext/pcre/pcrelib/.libs/pcre_exec.o ext/pcre/pcrelib/.libs/pcre_fullinfo.o ext/pcre/pcrelib/.libs/pcre_get.o ext/pcre/pcrelib/.libs/pcre_globals.o ext/pcre/pcrelib/.libs/pcre_info.o ext/pcre/pcrelib/.libs/pcre_maketables.o ext/pcre/pcrelib/.libs/pcre_newline.o ext/pcre/pcrelib/.libs/pcre_ord2utf8.o ext/pcre/pcrelib/.libs/pcre_refcount.o ext/pcre/pcrelib/.libs/pcre_study.o ext/pcre/pcrelib/.libs/pcre_tables.o ext/pcre/pcrelib/.libs/pcre_try_flipped.o ext/pcre/pcrelib/.libs/pcre_valid_utf8.o ext/pcre/pcrelib/.libs/pcre_version.o ext/pcre/pcrelib/.libs/pcre_xclass.o ext/pcre/.libs/php_pcre.o ext/zlib/.libs/zlib.o ext/zlib/.libs/zlib_fopen_wrapper.o ext/zlib/.libs/zlib_filter.o ext/bcmath/.libs/bcmath.o ext/bcmath/libbcmath/src/.libs/add.o ext/bcmath/libbcmath/src/.libs/div.o ext/bcmath/libbcmath/src/.libs/init.o ext/bcmath/libbcmath/src/.libs/neg.o ext/bcmath/libbcmath/src/.libs/outofmem.o ext/bcmath/libbcmath/src/.libs/raisemod.o ext/bcmath/libbcmath/src/.libs/rt.o ext/bcmath/libbcmath/src/.libs/sub.o ext/bcmath/libbcmath/src/.libs/compare.o ext/bcmath/libbcmath/src/.libs/divmod.o ext/bcmath/libbcmath/src/.libs/int2num.o ext/bcmath/libbcmath/src/.libs/num2long.o ext/bcmath/libbcmath/src/.libs/output.o ext/bcmath/libbcmath/src/.libs/recmul.o ext/bcmath/libbcmath/src/.libs/sqrt.o ext/bcmath/libbcmath/src/.libs/zero.o ext/bcmath/libbcmath/src/.libs/debug.o ext/bcmath/libbcmath/src/.libs/doaddsub.o ext/bcmath/libbcmath/src/.libs/nearzero.o ext/bcmath/libbcmath/src/.libs/num2str.o ext/bcmath/libbcmath/src/.libs/raise.o ext/bcmath/libbcmath/src/.libs/rmzero.o ext/bcmath/libbcmath/src/.libs/str2num.o ext/bz2/.libs/bz2.o ext/bz2/.libs/bz2_filter.o ext/calendar/.libs/calendar.o ext/calendar/.libs/dow.o ext/calendar/.libs/french.o ext/calendar/.libs/gregor.o ext/calendar/.libs/jewish.o ext/calendar/.libs/julian.o ext/calendar/.libs/easter.o ext/calendar/.libs/cal_unix.o ext/ctype/.libs/ctype.o ext/curl/.libs/interface.o ext/curl/.libs/multi.o ext/curl/.libs/streams.o ext/date/.libs/php_date.o ext/date/lib/.libs/astro.o ext/date/lib/.libs/dow.o ext/date/lib/.libs/parse_date.o ext/date/lib/.libs/parse_tz.o ext/date/lib/.libs/timelib.o ext/date/lib/.libs/tm2unixtime.o ext/date/lib/.libs/unixtime2tm.o ext/date/lib/.libs/parse_iso_intervals.o ext/date/lib/.libs/interval.o ext/dba/.libs/dba.o ext/dba/.libs/dba_cdb.o ext/dba/.libs/dba_dbm.o ext/dba/.libs/dba_gdbm.o ext/dba/.libs/dba_ndbm.o ext/dba/.libs/dba_db1.o ex
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 User updated by: kris dot craig at gmail dot com Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. Previous Comments: [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php [2008-08-05 02:43:54] kris dot craig at gmail dot com Description: Any time I enter a date (any format) into strtotime that contains a year later than 2037, the function returns FALSE every time. If I change the year to 2037 or earler, without changing anything else, it works every time. I have not been able to find any documentation or other information to explain this phenomenon. Pertinent server/module/etc information can be found here: http://www.kriscraig.com/phpinfo.php Reproduce code: --- /* This could not be simpler */ print strtotime( "2012-05-06" ); //1336287600 (works) print strtotime( "12 May 2037" ); //2125724400 (works) print strtotime( "12 May 2038" ); // (doesn't work!) print strtotime( "2500-05-06" ); // (doesn't work!) Expected result: They should all return a valid timestamp. FALSE should only be returned if it fails, which is not supposed to happen simply because the year being input is greater than 2037! Actual result: -- It returns FALSE. Nothing. Nada. -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 User updated by: kris dot craig at gmail dot com Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. Previous Comments: [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php [2008-08-05 02:43:54] kris dot craig at gmail dot com Description: Any time I enter a date (any format) into strtotime that contains a year later than 2037, the function returns FALSE every time. If I change the year to 2037 or earler, without changing anything else, it works every time. I have not been able to find any documentation or other information to explain this phenomenon. Pertinent server/module/etc information can be found here: http://www.kriscraig.com/phpinfo.php Reproduce code: --- /* This could not be simpler */ print strtotime( "2012-05-06" ); //1336287600 (works) print strtotime( "12 May 2037" ); //2125724400 (works) print strtotime( "12 May 2038" ); // (doesn't work!) print strtotime( "2500-05-06" ); // (doesn't work!) Expected result: They should all return a valid timestamp. FALSE should only be returned if it fails, which is not supposed to happen simply because the year being input is greater than 2037! Actual result: -- It returns FALSE. Nothing. Nada. -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 Updated by: [EMAIL PROTECTED] Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: Read it again, perhaps you then notice this one: "Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)" Of course, on a 64-bit platform this is not an issue. Previous Comments: [2008-08-05 19:59:39] kris dot craig at gmail dot com It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php [2008-08-05 02:43:54] kris dot craig at gmail dot com Description: Any time I enter a date (any format) into strtotime that contains a year later than 2037, the function returns FALSE every time. If I change the year to 2037 or earler, without changing anything else, it works every time. I have not been able to find any documentation or other information to explain this phenomenon. Pertinent server/module/etc information can be found here: http://www.kriscraig.com/phpinfo.php Reproduce code: --- /* This could not be simpler */ print strtotime( "2012-05-06" ); //1336287600 (works) print strtotime( "12 May 2037" ); //2125724400 (works) print strtotime( "12 May 2038" ); // (doesn't work!) print strtotime( "2500-05-06" ); // (doesn't work!) Expected result: They should all return a valid timestamp. FALSE should only be returned if it fails, which is not supposed to happen simply because the year being input is greater than 2037! Actual result: -- It returns FALSE. Nothing. Nada. -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 User updated by: kris dot craig at gmail dot com Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: You assume I don't already know that?? I told you, I've already researched this thoroughly. Yes, I am aware that this is the CAUSE of the bug, but it doesn't mean that it isn't still a bug nonetheless, it simply means that it'll be very difficult to solve. It is not bogus, and it was not appropriate to classify it as such. Instead, we should be talking about finding creative ways to solve the problem, other than just telling people to go out and get a 64-bit system. Perhaps try a different data type? Or return it as a string value if it goes beyond that size? These are just random ideas off the top of my head, of course, but my point is that there should be at least some deliberative effort put in to fixing this (or at least *discussing* ways to fix it) before simply dismissing it as "bogus" and insulting anyone who researches the issue and posts it as a bug report. Previous Comments: [2008-08-05 20:24:22] [EMAIL PROTECTED] Read it again, perhaps you then notice this one: "Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)" Of course, on a 64-bit platform this is not an issue. [2008-08-05 19:59:39] kris dot craig at gmail dot com It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php [2008-08-05 02:43:54] kris dot craig at gmail dot com Description: Any time I enter a date (any format) into strtotime that contains a year later than 2037, the function returns FALSE every time. If I change the year to 2037 or earler, without changing anything else, it works every time. I have not been able to find any documentation or other information to explain this phenomenon. Pertinent server/module/etc information can be found here: http://www.kriscraig.com/phpinfo.php Reproduce code: --- /* This could not be simpler */ print strtotime( "2012-05-06" ); //1336287600 (works) print strtotime( "12 May 2037" ); //2125724400 (works) print strtotime( "12 May 2038" ); // (doesn't work!) print strtotime( "2500-05-06" ); // (doesn't work!) Expected result: They should all return a valid timestamp. FALSE should only be returned if it fails, which is not supposed to happen simply because the year being input is greater than 2037! Actual result: -- It returns FALSE. Nothing. Nada. -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 Updated by: [EMAIL PROTECTED] Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: I already wrote about the alternative in my first comment, but because reading is obviously hard for you, I'll paste you the URL again: http://no.php.net/date_create Previous Comments: [2008-08-05 20:54:20] kris dot craig at gmail dot com You assume I don't already know that?? I told you, I've already researched this thoroughly. Yes, I am aware that this is the CAUSE of the bug, but it doesn't mean that it isn't still a bug nonetheless, it simply means that it'll be very difficult to solve. It is not bogus, and it was not appropriate to classify it as such. Instead, we should be talking about finding creative ways to solve the problem, other than just telling people to go out and get a 64-bit system. Perhaps try a different data type? Or return it as a string value if it goes beyond that size? These are just random ideas off the top of my head, of course, but my point is that there should be at least some deliberative effort put in to fixing this (or at least *discussing* ways to fix it) before simply dismissing it as "bogus" and insulting anyone who researches the issue and posts it as a bug report. [2008-08-05 20:24:22] [EMAIL PROTECTED] Read it again, perhaps you then notice this one: "Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)" Of course, on a 64-bit platform this is not an issue. [2008-08-05 19:59:39] kris dot craig at gmail dot com It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. [2008-08-05 06:48:23] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read *all* the documentation at: http://no.php.net/strtotime Alternatively, use the OO date/time functionality: http://no.php.net/manual/en/function.date-create.php 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/45713 -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713 User updated by: kris dot craig at gmail dot com Reported By: kris dot craig at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.6 New Comment: Perhaps you shouldn't be responding to these bug postings? You seem to respond only by hurling childish insults, this time belittling my intelligence by alleging that I don't know how to read. I did read your posts, including the suggestion about using date_create. But that is a workaround, not a solution. A solution would be fixing strtotime() and other similar functions so that they can accept a year past 2037-- some have said it's like "Unix's Y2K"; i.e. we're going to have to address it eventually, so why wait 'till the last minute? At very least, we should update the documentation on that function to clearly outline this limitation, including the reasons behind it, and a suggested workaround. However, I think that should be the "Plan B" resolution, in the event that we can't find something better. But we won't if you keep reducing the level of this dialogue by including childish, non-constructive, unprofessional insults in your responses. Previous Comments: [2008-08-05 21:13:41] [EMAIL PROTECTED] I already wrote about the alternative in my first comment, but because reading is obviously hard for you, I'll paste you the URL again: http://no.php.net/date_create [2008-08-05 20:54:20] kris dot craig at gmail dot com You assume I don't already know that?? I told you, I've already researched this thoroughly. Yes, I am aware that this is the CAUSE of the bug, but it doesn't mean that it isn't still a bug nonetheless, it simply means that it'll be very difficult to solve. It is not bogus, and it was not appropriate to classify it as such. Instead, we should be talking about finding creative ways to solve the problem, other than just telling people to go out and get a 64-bit system. Perhaps try a different data type? Or return it as a string value if it goes beyond that size? These are just random ideas off the top of my head, of course, but my point is that there should be at least some deliberative effort put in to fixing this (or at least *discussing* ways to fix it) before simply dismissing it as "bogus" and insulting anyone who researches the issue and posts it as a bug report. [2008-08-05 20:24:22] [EMAIL PROTECTED] Read it again, perhaps you then notice this one: "Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)" Of course, on a 64-bit platform this is not an issue. [2008-08-05 19:59:39] kris dot craig at gmail dot com It should be noted that this bug has been reported numerous times over the last few years (though not recently), and this is the first time anyone ever responded by trying to claim that it's somehow bogus. [2008-08-05 19:49:18] kris dot craig at gmail dot com Excuse me, but this is a bug, and it is NOT bogus. I have consulted the documentation. Unless you can provide some sort of solution to this problem or at least explain why you don't think it's a bug that PHP won't handle any year past 2037, then I will re-post this bug in hopes that the next person who looks it over will actually give it some deliberative thought before dismissing it. 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/45713 -- Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713
Updated by: [EMAIL PROTECTED]
Reported By: kris dot craig at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 5.2.6
New Comment:
Derick has given you a solution, use the new DateTime class.
$date = new DateTime("12 May 2038"); echo $date->format("U");
Previous Comments:
[2008-08-05 21:21:06] kris dot craig at gmail dot com
Perhaps you shouldn't be responding to these bug postings? You seem to
respond only by hurling childish insults, this time belittling my
intelligence by alleging that I don't know how to read. I did read your
posts, including the suggestion about using date_create. But that is a
workaround, not a solution. A solution would be fixing strtotime() and
other similar functions so that they can accept a year past 2037-- some
have said it's like "Unix's Y2K"; i.e. we're going to have to address it
eventually, so why wait 'till the last minute?
At very least, we should update the documentation on that function to
clearly outline this limitation, including the reasons behind it, and a
suggested workaround. However, I think that should be the "Plan B"
resolution, in the event that we can't find something better. But we
won't if you keep reducing the level of this dialogue by including
childish, non-constructive, unprofessional insults in your responses.
[2008-08-05 21:13:41] [EMAIL PROTECTED]
I already wrote about the alternative in my first comment, but because
reading is obviously hard for you, I'll paste you the URL again:
http://no.php.net/date_create
[2008-08-05 20:54:20] kris dot craig at gmail dot com
You assume I don't already know that?? I told you, I've already
researched this thoroughly. Yes, I am aware that this is the CAUSE of
the bug, but it doesn't mean that it isn't still a bug nonetheless, it
simply means that it'll be very difficult to solve. It is not bogus,
and it was not appropriate to classify it as such.
Instead, we should be talking about finding creative ways to solve the
problem, other than just telling people to go out and get a 64-bit
system. Perhaps try a different data type? Or return it as a string
value if it goes beyond that size? These are just random ideas off the
top of my head, of course, but my point is that there should be at least
some deliberative effort put in to fixing this (or at least *discussing*
ways to fix it) before simply dismissing it as "bogus" and insulting
anyone who researches the issue and posts it as a bug report.
[2008-08-05 20:24:22] [EMAIL PROTECTED]
Read it again, perhaps you then notice this one:
"Note: The valid range of a timestamp is typically from Fri, 13 Dec
1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates
that correspond to the minimum and maximum values for a 32-bit signed
integer.)"
Of course, on a 64-bit platform this is not an issue.
[2008-08-05 19:59:39] kris dot craig at gmail dot com
It should be noted that this bug has been reported numerous times over
the last few years (though not recently), and this is the first time
anyone ever responded by trying to claim that it's somehow bogus.
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/45713
--
Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45713 [Bgs]: Function strtotime() always returns FALSE if year > 2037!!
ID: 45713
User updated by: kris dot craig at gmail dot com
Reported By: kris dot craig at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows
PHP Version: 5.2.6
New Comment:
No, he hasn't. That isn't a solution. It's a workaround. I already
said that in my last post.
If this is the best we can do, then strtotime() should be depreciated,
and the PHP documentation should point all users to the new DateTime
class.
Either way, this isn't a solution as it stands now. At very least the
documentation for strtotime() needs some serious updating.
Previous Comments:
[2008-08-05 22:08:22] [EMAIL PROTECTED]
Derick has given you a solution, use the new DateTime class.
$date = new DateTime("12 May 2038"); echo $date->format("U");
[2008-08-05 21:21:06] kris dot craig at gmail dot com
Perhaps you shouldn't be responding to these bug postings? You seem to
respond only by hurling childish insults, this time belittling my
intelligence by alleging that I don't know how to read. I did read your
posts, including the suggestion about using date_create. But that is a
workaround, not a solution. A solution would be fixing strtotime() and
other similar functions so that they can accept a year past 2037-- some
have said it's like "Unix's Y2K"; i.e. we're going to have to address it
eventually, so why wait 'till the last minute?
At very least, we should update the documentation on that function to
clearly outline this limitation, including the reasons behind it, and a
suggested workaround. However, I think that should be the "Plan B"
resolution, in the event that we can't find something better. But we
won't if you keep reducing the level of this dialogue by including
childish, non-constructive, unprofessional insults in your responses.
[2008-08-05 21:13:41] [EMAIL PROTECTED]
I already wrote about the alternative in my first comment, but because
reading is obviously hard for you, I'll paste you the URL again:
http://no.php.net/date_create
[2008-08-05 20:54:20] kris dot craig at gmail dot com
You assume I don't already know that?? I told you, I've already
researched this thoroughly. Yes, I am aware that this is the CAUSE of
the bug, but it doesn't mean that it isn't still a bug nonetheless, it
simply means that it'll be very difficult to solve. It is not bogus,
and it was not appropriate to classify it as such.
Instead, we should be talking about finding creative ways to solve the
problem, other than just telling people to go out and get a 64-bit
system. Perhaps try a different data type? Or return it as a string
value if it goes beyond that size? These are just random ideas off the
top of my head, of course, but my point is that there should be at least
some deliberative effort put in to fixing this (or at least *discussing*
ways to fix it) before simply dismissing it as "bogus" and insulting
anyone who researches the issue and posts it as a bug report.
[2008-08-05 20:24:22] [EMAIL PROTECTED]
Read it again, perhaps you then notice this one:
"Note: The valid range of a timestamp is typically from Fri, 13 Dec
1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates
that correspond to the minimum and maximum values for a 32-bit signed
integer.)"
Of course, on a 64-bit platform this is not an issue.
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/45713
--
Edit this bug report at http://bugs.php.net/?id=45713&edit=1
#45615 [Com]: 5.2.6 distributes only a white page
ID: 45615 Comment by: japan at email dot de Reported By: japan at email dot de Status: Feedback Bug Type: IIS related Operating System: W2K3 or WXP PHP Version: 5.2.6 New Comment: Hi jani, I test the CVS versions (manual as MSI installation) every day since my error message. All the CVS versions 5.2-dev and 5.3-dev since 24.07.2008 still have the problem reported by me. I would like to tell you something else but unfortunately, it is it like me describe. greetings - Helmut Previous Comments: [2008-07-31 23:11:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-07-24 14:39:12] japan at email dot de Description: PHP v5.2.6 distributes only a white page over an microsoft IIS 6! Both distributions that is about the Windows Installer MSI as well as by ZIP in a manual installation method have the same faulty result. The older version 5.2.5 has this problem neither with the Windows Installer MSI nor with the manual installation method. -- Edit this bug report at http://bugs.php.net/?id=45615&edit=1
#45697 [Com]: ISAPI mode header() doesnt send any headers
ID: 45697 Comment by: japan at email dot de Reported By: beezlebob666 at yahoo dot com Status: Open Bug Type: IIS related Operating System: XP Pro PHP Version: 5.2.6 New Comment: This sounds like a comparable Sympom of my error message Bug # 45615 of the 2008-07-24 Previous Comments: [2008-08-03 11:01:06] beezlebob666 at yahoo dot com Description: In ISAPI mode on IIS on XP, header() does not send anything to the browser. Pear not installed, zend not installed, all .dll files unloaded, default php.ini-dist used. Uninstalled and reinstalled as a CGI mode and it appears to work fine. Reproduce code: --- Expected result: Expected to redirect to any 404 page. Actual result: -- Blank page with no content. -- Edit this bug report at http://bugs.php.net/?id=45697&edit=1
#45728 [NEW]: Static references via Variable Variables
From: thinice at gmail dot com
Operating system: FreeBSD
PHP version: 5.2.6
PHP Bug Type: Variables related
Bug description: Static references via Variable Variables
Description:
When you try to access a static variable within a class using a variable
variable to determine which class and static to use.
Reproduce code:
---
";
$s = $sClass.'::$myVar';
echo "Using this as the string: ".$s."";
echo "Using Variable-named reference: ".${$s};
?>
Expected result:
Expected output: testval
Using this as the string: MyTest::$myVar
Using Variable-named reference: testval
Actual result:
--
Expected output: testval
Using this as the string: MyTest::$myVar
Using Variable-named reference:
--
Edit bug report at http://bugs.php.net/?id=45728&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45728&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45728&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45728&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45728&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45728&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45728&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45728&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45728&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45728&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45728&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45728&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45728&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45728&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45728&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45728&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45728&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45728&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45728&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45728&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45728&r=mysqlcfg
#44313 [Opn->Bgs]: inconsistencies in property assignation on scalar variables
ID: 44313 Updated by: [EMAIL PROTECTED] Reported By: johann dot queuniet at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.2.5 New Comment: AS Felipe said, it's for BC and you do get warning with E_STRICT. Previous Comments: [2008-03-02 21:33:08] [EMAIL PROTECTED] Using E_STRICT, "Strict Standards: Creating default object from empty value" are showed for other cases. [2008-03-02 18:19:19] johann dot queuniet at gmail dot com Description: The way PHP handles property assignation on scalar variables evaluating as false is inconsistent. Reproduce code: --- test = true; $var2 = null; $var2->test = true; $var3 = false; $var3->test = true; $var3 = ''; $var3->test = true; $var4 = 0; $var4->test = true; $var5 = '0'; $var5->test = true; $var6 = array(); $var6->test = true; ?> Expected result: PHP should handle every case the same way, with a "Warning: Attempt to assign property of non-object". The first line should also trigger a notice since the $var1 variable is undeclared. Actual result: -- PHP behaves as with arrays and only triggers a warning for the last three. The other lines create an stdClass object with the test property set. -- Edit this bug report at http://bugs.php.net/?id=44313&edit=1
#43229 [Asn->WFx]: array_walk() crashes with a segmentation fault
ID: 43229 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Wont fix Bug Type: Scripting Engine problem Operating System: CentOS PHP Version: 5.2CVS-2008-03-25 (CVS) Assigned To: dmitry Previous Comments: [2008-04-14 11:23:16] [EMAIL PROTECTED] The crash is not related to variable name. It occurs because the script unset()s the element of array which is still referenced from the array_walk() function. So later array_walk() tries to access freed memory and may crash. The array_walk() manual says: Users may not change the array itself from the callback function. e.g. Add/delete elements, unset elements, etc. If the array that array_walk() is applied to is changed, the behavior of this function is undefined, and unpredictable. I think this bug shouldn't be fixed. [2008-04-12 14:54:09] [EMAIL PROTECTED] Dmitry, can you please check this out? It's pretty bad if just a certain name of variable causes a crash. [2008-03-25 13:52:12] [EMAIL PROTECTED] Still crashes using latest 5.2 snapshot. [2008-02-09 01:10:05] [EMAIL PROTECTED] Still creashes for me in 5.3CVS. Please do not re-close without ensuring a fix - UMRs or memory corruption can be elusive and not show on some environments while existing on others. [2008-01-22 13:45:26] [EMAIL PROTECTED] Works fine to me. PHP 5.3.0-dev (cli) (built: Jan 18 2008 12:20:16) 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/43229 -- Edit this bug report at http://bugs.php.net/?id=43229&edit=1
#45727 [Opn->Bgs]: DOMDocument::load() is not reporting errors on malformed XML
ID: 45727
Updated by: [EMAIL PROTECTED]
Reported By: mephtu at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: DOM XML related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
I get
"Warning: DOMDocument::load(): Opening and ending tag mismatch: tags
line 1 and ags in /Users/chregu/tmp/foo.xml, line: 1 in
/Users/chregu/tmp/foo.php on line 3"
what is to be expected.
Do you have set the error level correctly? Does it really die after
load? The script shouldn't stop there.
and maybe http://ch2.php.net/manual/en/function.libxml-use-internal-
errors.php is of help for you
Previous Comments:
[2008-08-05 15:04:44] mephtu at yahoo dot com
Description:
Loading a malformed XML document with DOMDocument::load() fails to
report any errors.
Reproduce code:
---
load.php:
load('malformed.xml');
?>
malformed.xml:
data
Expected result:
I expected to see an error message.
Actual result:
--
Parser dies silently without reporting error.
--
Edit this bug report at http://bugs.php.net/?id=45727&edit=1
#45697 [Opn]: ISAPI mode header() doesnt send any headers
ID: 45697 User updated by: beezlebob666 at yahoo dot com Reported By: beezlebob666 at yahoo dot com Status: Open Bug Type: IIS related Operating System: XP Pro PHP Version: 5.2.6 New Comment: Oh and for the record, I have tried setting php.ini with the following: ; if cgi.nph is enabled it will force cgi to always sent Status: 200 with ; every request. cgi.nph = 0 cgi.rfc2616_headers = 0 Although its not in cgi mode,its ISAPI mode so, despite my inexperience, makes sense to try, but it didnt resolve the issue. I have also run a header scanner on my server also, and even though I dont see it, its as if the server is sending a Status: 200 OK before sending Status: 404 Previous Comments: [2008-08-06 00:18:08] japan at email dot de This sounds like a comparable Sympom of my error message Bug # 45615 of the 2008-07-24 [2008-08-03 11:01:06] beezlebob666 at yahoo dot com Description: In ISAPI mode on IIS on XP, header() does not send anything to the browser. Pear not installed, zend not installed, all .dll files unloaded, default php.ini-dist used. Uninstalled and reinstalled as a CGI mode and it appears to work fine. Reproduce code: --- Expected result: Expected to redirect to any 404 page. Actual result: -- Blank page with no content. -- Edit this bug report at http://bugs.php.net/?id=45697&edit=1
#42791 [Com]: HTML img src tag resets session variable
ID: 42791 Comment by: hardik dot akbari at yahoo dot com Reported By: dron007 at yahoo dot com Status: No Feedback Bug Type: Session related Operating System: Linux PHP Version: 5.2.4 New Comment: i am facing the same problem in internet explorer. in ie 7 , resets session variables. i am using apache 2.2.9 , php 5.2.7-dev. this seems browser problem than php.. Previous Comments: [2007-11-27 16:40:45] martin at limitless dot co dot uk I have recently come across this bug in PHP Version 5.1.4. The code was that caused the session variables to reset. The system is running Apache 1.3 on Solaris 10. If I can provide any other useful information, just let me know. [2007-10-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-10-01 10:37:44] dron007 at inbox dot ru Yes, that was IE6. With FF and Opera everything works fine. Probably that is browser issue but it is very weird thing because if I add another session variable that is not nulled IE shows this variable and doesn't show nulled one. FF shows both of them. That means that session cookie is sent in both cases. Also if I move $_SESSION["some_var"] = null; inside "if" statement it works fine too. [2007-09-29 02:36:46] [EMAIL PROTECTED] With what browser are you trying this with? IIRC, there was some issue with IE and broken html and it not sending some headers then. [2007-09-28 17:55:24] dron007 at yahoo dot com Description: There was the bug already posted: http://bugs.php.net/bug.php?id=25966 I also have the similar situation. IMG tag with empty src attribute deletes session variable. Yes, it is incorrect tag but I spent a lot of time debugging this situation and I was very surprized that HTML code have an influence on PHP variables. Reproduce code: --- File 1.php: Goto 2 --- File 2.php: '; echo ''; ?> Expected result: I first load file 1.php, then go by link which sets session variable, then I see "some_var=1" which is correct. If I reload 2.php I expect to see "some_var=1" Actual result: -- "some_var=" Session variable is destroyed. -- Edit this bug report at http://bugs.php.net/?id=42791&edit=1
#42791 [Com]: HTML img src tag resets session variable
ID: 42791 Comment by: hardik dot akbari at etatvasoft dot com Reported By: dron007 at yahoo dot com Status: No Feedback Bug Type: Session related Operating System: Linux PHP Version: 5.2.4 New Comment: i think this is one of the possible reason for this bug. causes IE 7 to reset php session variable... so put a check that src attribute should not be blank.. Previous Comments: [2008-08-06 05:45:51] hardik dot akbari at yahoo dot com i am facing the same problem in internet explorer. in ie 7 , resets session variables. i am using apache 2.2.9 , php 5.2.7-dev. this seems browser problem than php.. [2007-11-27 16:40:45] martin at limitless dot co dot uk I have recently come across this bug in PHP Version 5.1.4. The code was that caused the session variables to reset. The system is running Apache 1.3 on Solaris 10. If I can provide any other useful information, just let me know. [2007-10-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-10-01 10:37:44] dron007 at inbox dot ru Yes, that was IE6. With FF and Opera everything works fine. Probably that is browser issue but it is very weird thing because if I add another session variable that is not nulled IE shows this variable and doesn't show nulled one. FF shows both of them. That means that session cookie is sent in both cases. Also if I move $_SESSION["some_var"] = null; inside "if" statement it works fine too. [2007-09-29 02:36:46] [EMAIL PROTECTED] With what browser are you trying this with? IIRC, there was some issue with IE and broken html and it not sending some headers then. 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/42791 -- Edit this bug report at http://bugs.php.net/?id=42791&edit=1
