#17868 [Com]: Doesn't work two and more directives of PHP code on different OS
ID: 17868 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: * PHP Version: 4.3.0-dev New Comment: RE: apache2 & php developers not working together. I agree. infact 2 apache2 developers spent a couple of hours and created a new php/apache2 sapi interface, and It would be great if you could give it a try and send some feedback if you could try the --with-apxs2handler instead of --with-apxs2 this might help. this uses the standard handler mechanism, and not the filter API. look forward to hearding how it goes. Ian Previous Comments: [2003-02-12 13:54:03] [EMAIL PROTECTED] Both. [2003-02-12 13:50:53] [EMAIL PROTECTED] When you say "This bug has been fixed in CVS" do you mean 4.3.x-dev or 5.0.x-dev? [2003-01-28 10:35:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-21 13:11:16] [EMAIL PROTECTED] I have run accross this as well on IIS5 and Win2k so it isn't limited to just Apache. Going back to PHP 4.2.3 resolves the issue but 4.3.0 will only acknowledge the first include and then page halts loading when the second is encountered. [2003-01-17 08:13:29] [EMAIL PROTECTED] reproduced with apache 2.0.39 php 4.2.2 and php 4.3.0 apache 2.0.43 php 4.2.2 and php 4.3.0 linux kernel 2.4.19 gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81) if php is built as module, the rest of includes output php's code without interpretation 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/17868 -- Edit this bug report at http://bugs.php.net/?id=17868&edit=1
Bug #15217 Updated: syntax error before `va_list'
ID: 15217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: FreeBSD PHP Version: 4.1.1 New Comment: I'm getting the same error in 4.5-20020402-STABLE. Previous Comments: [2002-03-03 02:27:46] [EMAIL PROTECTED] works fine in FreeBSD 4.5 [2002-01-25 01:16:07] [EMAIL PROTECTED] I run ./configure and whether or not I pass arguments I receive this error on 'make'. This is the very first step in the build: Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -I../TSRM -g -O2 -prefer-non-pic -static -c zend_language_parser.c In file included from zend.h:164, from zend_compile.h:24, from zend_language_parser.c:148: zend_hash.h:119: syntax error before `va_list' In file included from zend.h:165, from zend_compile.h:24, from zend_language_parser.c:148: zend_llist.h:34: syntax error before `va_list' In file included from zend_compile.h:24, from zend_language_parser.c:148: zend.h:247: syntax error before `va_list' zend.h:378: syntax error before `va_list' *** Error code 1 Stop in /usr/sources/php-4.1.1/Zend. *** Error code 1 Stop in /usr/sources/php-4.1.1. Some previous bug reports I've seen were similar, but for previous versions. I tried some code edits anyway, with their ideas in mind, but to no avail. I'm starting to think my FreeBSD 4.4 STABLE build is broken. Thanks in advance :-) -- Edit this bug report at http://bugs.php.net/?id=15217&edit=1
#26248 [Bgs]: Can't compile PHP (both 4 and 5) with IMAP
ID: 26248 User updated by: lists at nutshell dot nu Reported By: lists at nutshell dot nu Status: Bogus Bug Type: Compile Failure Operating System: Linux (Mandrake 9.2) PHP Version: 5.0.0b2 (beta2) New Comment: In my view there is a bug since compilation fails due to this even when I configure the php imap not to support kerberos and ssl. Previous Comments: [2003-11-28 20:29:20] [EMAIL PROTECTED] Yes, you need to have libc-client.a. There is no bug here. [2003-11-18 08:14:12] lists at nutshell dot nu A few notes to my last comment. To be able to compile php (4/5) you either have to compile imap from a tar ball or change the imap.spec so it compiles the libc-client-PHP4.a with kerberos (it only compiles with ssl default). My experience here is that it is impossible to compile imap support for php unless you have kerberos. In my original post I show that I tried with both --without-kerberos and --without-imap-ssl, but the compilation failed due to that libc-client had no kerberos support. [2003-11-17 20:33:49] lists at nutshell dot nu I think I have found the problem. Mandrake builds three c-clients. libc-client.a libc-client-PHP4.a libc-client-nossl.a Note than the -PHP4 is built without kerberos support. I renamed libc-client.a to libc-client-org.a and libc-client-PHP4.a to libc-client.a. Then PHP5 compiles just fine with a shared imap. Is there any way of building without having to rename the libs? [2003-11-16 14:25:38] lists at nutshell dot nu Yes, as stated in my original post it fails both with and without shared. I have tried every possible combination I can think of. It compiles just fine without imap, but I need imap. Can also add that Mandrake 9.2 comes with a php imap rpm and the only things I compile from tar-balls are apache and php4/5. [2003-11-16 13:16:33] [EMAIL PROTECTED] Does it fail if you do not compile imap as a shared extension? 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/26248 -- Edit this bug report at http://bugs.php.net/?id=26248&edit=1
#30828 [NEW]: debug_backtrace reports incorrect class in overridden methods
From: lists at infospleen dot com
Operating system:
PHP version: 5.0.1
PHP Bug Type: Scripting Engine problem
Bug description: debug_backtrace reports incorrect class in overridden methods
Description:
If class B extends class A, and overrides a method of class A,
debug_backtrace() reports that the method of class A is a method of class
B instead.
Reproduce code:
---
class A {
function __construct() {
$bt = debug_backtrace();
foreach ($bt as $t)
print
$t['class'].'::'.
$t['function'].'';
}
}
class B extends A {
function __construct() {
parent::__construct();
}
}
$b = new B();
Expected result:
Expected output:
A::__construct
B::__construct
Actual result:
--
Actual output:
B::__construct
B::__construct
--
Edit bug report at http://bugs.php.net/?id=30828&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30828&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30828&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30828&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30828&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30828&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30828&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30828&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30828&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30828&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30828&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30828&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30828&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30828&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30828&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30828&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30828&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30828&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30828&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30828&r=mysqlcfg
#26248 [NEW]: Can't compile PHP (both 4 and 5) with IMAP
From: lists at nutshell dot nu Operating system: Linux (Mandrake 9.2) PHP version: 5.0.0b2 (beta2) PHP Bug Type: Compile Failure Bug description: Can't compile PHP (both 4 and 5) with IMAP Description: Please note that Mandrake 9.2 comes with a mod-imap for php4, but I wanted to compile it to suite my needs. I have tryed compiling php5 (b2 and later snapshots, as well as latest official php4) with imap. I have tried with Mandrake 9.2's own imap-2002d, recompiling it with "rpm -bb --target i686", as well as downgrading to imap-2001a. I have tried to configure with: --with-imap=shared --with-imap-ssl or --with-imap=shared --without-imap-ssl or --with-imap=shared Plus also adding "/usr" as dir and without shared. Note that if I try to configure "--without-kerberos" the configure stops at imap. I have all normal and devel packages installed for imap, openssl and keberos, as well as any util packages for them. ./configure works just fine, but when I run make I get errors. I get the following error: /usr/local/src/php5-200311122030/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: `auth_gss' undeclared (first use in this function) /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: (Each undeclared identifier is reported only once /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=26248&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26248&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26248&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26248&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26248&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26248&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26248&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26248&r=support Expected behavior: http://bugs.php.net/fix.php?id=26248&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26248&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26248&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26248&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26248&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26248&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26248&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26248&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26248&r=float
#26248 [Fbk->Opn]: Can't compile PHP (both 4 and 5) with IMAP
ID: 26248 User updated by: lists at nutshell dot nu Reported By: lists at nutshell dot nu -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Linux (Mandrake 9.2) PHP Version: 5.0.0b2 (beta2) New Comment: Yes, as stated in my original post it fails both with and without shared. I have tried every possible combination I can think of. It compiles just fine without imap, but I need imap. Can also add that Mandrake 9.2 comes with a php imap rpm and the only things I compile from tar-balls are apache and php4/5. Previous Comments: [2003-11-16 13:16:33] [EMAIL PROTECTED] Does it fail if you do not compile imap as a shared extension? [2003-11-14 04:52:38] lists at nutshell dot nu Description: Please note that Mandrake 9.2 comes with a mod-imap for php4, but I wanted to compile it to suite my needs. I have tryed compiling php5 (b2 and later snapshots, as well as latest official php4) with imap. I have tried with Mandrake 9.2's own imap-2002d, recompiling it with "rpm -bb --target i686", as well as downgrading to imap-2001a. I have tried to configure with: --with-imap=shared --with-imap-ssl or --with-imap=shared --without-imap-ssl or --with-imap=shared Plus also adding "/usr" as dir and without shared. Note that if I try to configure "--without-kerberos" the configure stops at imap. I have all normal and devel packages installed for imap, openssl and keberos, as well as any util packages for them. ./configure works just fine, but when I run make I get errors. I get the following error: /usr/local/src/php5-200311122030/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: `auth_gss' undeclared (first use in this function) /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: (Each undeclared identifier is reported only once /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=26248&edit=1
#26248 [Opn]: Can't compile PHP (both 4 and 5) with IMAP
ID: 26248 User updated by: lists at nutshell dot nu Reported By: lists at nutshell dot nu Status: Open Bug Type: Compile Failure Operating System: Linux (Mandrake 9.2) PHP Version: 5.0.0b2 (beta2) New Comment: I think I have found the problem. Mandrake builds three c-clients. libc-client.a libc-client-PHP4.a libc-client-nossl.a Note than the -PHP4 is built without kerberos support. I renamed libc-client.a to libc-client-org.a and libc-client-PHP4.a to libc-client.a. Then PHP5 compiles just fine with a shared imap. Is there any way of building without having to rename the libs? Previous Comments: [2003-11-16 14:25:38] lists at nutshell dot nu Yes, as stated in my original post it fails both with and without shared. I have tried every possible combination I can think of. It compiles just fine without imap, but I need imap. Can also add that Mandrake 9.2 comes with a php imap rpm and the only things I compile from tar-balls are apache and php4/5. [2003-11-16 13:16:33] [EMAIL PROTECTED] Does it fail if you do not compile imap as a shared extension? [2003-11-14 04:52:38] lists at nutshell dot nu Description: Please note that Mandrake 9.2 comes with a mod-imap for php4, but I wanted to compile it to suite my needs. I have tryed compiling php5 (b2 and later snapshots, as well as latest official php4) with imap. I have tried with Mandrake 9.2's own imap-2002d, recompiling it with "rpm -bb --target i686", as well as downgrading to imap-2001a. I have tried to configure with: --with-imap=shared --with-imap-ssl or --with-imap=shared --without-imap-ssl or --with-imap=shared Plus also adding "/usr" as dir and without shared. Note that if I try to configure "--without-kerberos" the configure stops at imap. I have all normal and devel packages installed for imap, openssl and keberos, as well as any util packages for them. ./configure works just fine, but when I run make I get errors. I get the following error: /usr/local/src/php5-200311122030/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: `auth_gss' undeclared (first use in this function) /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: (Each undeclared identifier is reported only once /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=26248&edit=1
#26248 [Opn]: Can't compile PHP (both 4 and 5) with IMAP
ID: 26248 User updated by: lists at nutshell dot nu Reported By: lists at nutshell dot nu Status: Open Bug Type: Compile Failure Operating System: Linux (Mandrake 9.2) PHP Version: 5.0.0b2 (beta2) New Comment: A few notes to my last comment. To be able to compile php (4/5) you either have to compile imap from a tar ball or change the imap.spec so it compiles the libc-client-PHP4.a with kerberos (it only compiles with ssl default). My experience here is that it is impossible to compile imap support for php unless you have kerberos. In my original post I show that I tried with both --without-kerberos and --without-imap-ssl, but the compilation failed due to that libc-client had no kerberos support. Previous Comments: [2003-11-17 20:33:49] lists at nutshell dot nu I think I have found the problem. Mandrake builds three c-clients. libc-client.a libc-client-PHP4.a libc-client-nossl.a Note than the -PHP4 is built without kerberos support. I renamed libc-client.a to libc-client-org.a and libc-client-PHP4.a to libc-client.a. Then PHP5 compiles just fine with a shared imap. Is there any way of building without having to rename the libs? [2003-11-16 14:25:38] lists at nutshell dot nu Yes, as stated in my original post it fails both with and without shared. I have tried every possible combination I can think of. It compiles just fine without imap, but I need imap. Can also add that Mandrake 9.2 comes with a php imap rpm and the only things I compile from tar-balls are apache and php4/5. [2003-11-16 13:16:33] [EMAIL PROTECTED] Does it fail if you do not compile imap as a shared extension? [2003-11-14 04:52:38] lists at nutshell dot nu Description: Please note that Mandrake 9.2 comes with a mod-imap for php4, but I wanted to compile it to suite my needs. I have tryed compiling php5 (b2 and later snapshots, as well as latest official php4) with imap. I have tried with Mandrake 9.2's own imap-2002d, recompiling it with "rpm -bb --target i686", as well as downgrading to imap-2001a. I have tried to configure with: --with-imap=shared --with-imap-ssl or --with-imap=shared --without-imap-ssl or --with-imap=shared Plus also adding "/usr" as dir and without shared. Note that if I try to configure "--without-kerberos" the configure stops at imap. I have all normal and devel packages installed for imap, openssl and keberos, as well as any util packages for them. ./configure works just fine, but when I run make I get errors. I get the following error: /usr/local/src/php5-200311122030/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: `auth_gss' undeclared (first use in this function) /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: (Each undeclared identifier is reported only once /usr/local/src/php5-200311122030/ext/imap/php_imap.c:445: error: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=26248&edit=1
#26248 [Bgs->Opn]: Can't compile PHP (both 4 and 5) with IMAP
ID: 26248 User updated by: lists at nutshell dot nu Reported By: lists at nutshell dot nu -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: Linux (Mandrake 9.2) PHP Version: 5.0.0b2 (beta2) New Comment: What works fine for you and on what distribution? How did you for example run the configure to get it work? I have to say that the manual for php isn't very helpful regarding configure and compiling... Previous Comments: [2003-11-18 15:29:14] [EMAIL PROTECTED] Works fine for me. [2003-11-18 08:14:12] lists at nutshell dot nu A few notes to my last comment. To be able to compile php (4/5) you either have to compile imap from a tar ball or change the imap.spec so it compiles the libc-client-PHP4.a with kerberos (it only compiles with ssl default). My experience here is that it is impossible to compile imap support for php unless you have kerberos. In my original post I show that I tried with both --without-kerberos and --without-imap-ssl, but the compilation failed due to that libc-client had no kerberos support. [2003-11-17 20:33:49] lists at nutshell dot nu I think I have found the problem. Mandrake builds three c-clients. libc-client.a libc-client-PHP4.a libc-client-nossl.a Note than the -PHP4 is built without kerberos support. I renamed libc-client.a to libc-client-org.a and libc-client-PHP4.a to libc-client.a. Then PHP5 compiles just fine with a shared imap. Is there any way of building without having to rename the libs? [2003-11-16 14:25:38] lists at nutshell dot nu Yes, as stated in my original post it fails both with and without shared. I have tried every possible combination I can think of. It compiles just fine without imap, but I need imap. Can also add that Mandrake 9.2 comes with a php imap rpm and the only things I compile from tar-balls are apache and php4/5. [2003-11-16 13:16:33] [EMAIL PROTECTED] Does it fail if you do not compile imap as a shared extension? 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/26248 -- Edit this bug report at http://bugs.php.net/?id=26248&edit=1
#29714 [NEW]: getopt does not reset
From: lists at cyberlot dot net Operating system: Fedora Core 2 PHP version: 5.0.0 PHP Bug Type: Feature/Change Request Bug description: getopt does not reset Description: You can only call getopt a single time and get results. Getopt should reset what ever pointers it uses to ensure state is as it was prior to calling getopt. An example.. A modular based system using a config file or command line to load a module, It is impossible for the module to use getopt to look for module specific settings because getopt has already been called by the main engine. ./engine -loadmod abc -abcdb 123 It is impossible for mod abc to realize it needs to load database 123 because any attempts to run getopt based on those new params fail. Reproduce code: --- Expected result: [EMAIL PROTECTED] streams]# php test.php -c 1 Array ( [c] => 1 ) Array ( [c] => 1 ) Actual result: -- [EMAIL PROTECTED] streams]# php test.php -c 1 Array ( [c] => 1 ) Array ( ) -- Edit bug report at http://bugs.php.net/?id=29714&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29714&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29714&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29714&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29714&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29714&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29714&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29714&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29714&r=support Expected behavior: http://bugs.php.net/fix.php?id=29714&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29714&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29714&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29714&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29714&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29714&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29714&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29714&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29714&r=float
#29726 [NEW]: Streams socket functionality
From: lists at cyberlot dot net Operating system: Fedora Core 2 PHP version: 5.0.1 PHP Bug Type: Sockets related Bug description: Streams socket functionality Description: switched from socket functions to stream functions for socket server usage because streams is supposed to be stable, and are included by default.. The problem socket_read supports PHP_NORMAL_READ which allows it to see flashes \0 as EOL... This is not possible when using streams to create a socket server as fget does not see \0 as EOL Expected result: Expect fgets to return data at \0 Actual result: -- Nothing is returned until the buffer is filled. -- Edit bug report at http://bugs.php.net/?id=29726&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29726&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29726&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29726&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29726&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29726&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29726&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29726&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29726&r=support Expected behavior: http://bugs.php.net/fix.php?id=29726&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29726&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29726&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29726&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29726&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29726&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29726&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29726&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29726&r=float
#29726 [Opn]: Streams socket functionality
ID: 29726 User updated by: lists at cyberlot dot net Reported By: lists at cyberlot dot net Status: Open Bug Type: Sockets related Operating System: Fedora Core 2 PHP Version: 5.0.1 New Comment: This problem only exists with fread, fget which multiple examples in the docs use and the docs list as "See Also" functions. However by using stream_socket_recvfrom this problem was resovled.. This function is not at this time referenced in the manual other in the functions list so might easily overlooked as I did. One possible issue I do see, stream_socket_recvfrom looks to work because it pulls everything in the buffer up to X bytes regardless of any EOL character. On a slow single line entry settup this shouldn't be a problem and everything should work fine.. Under high load when data ends up being buffered at both sides this function would return only partial "blocks" of what a user might expect and the user would need to program his own internal buffering that checks for EOL. This should be covered in more detail in the online manual. Previous Comments: ---- [2004-08-18 00:59:26] lists at cyberlot dot net Description: switched from socket functions to stream functions for socket server usage because streams is supposed to be stable, and are included by default.. The problem socket_read supports PHP_NORMAL_READ which allows it to see flashes \0 as EOL... This is not possible when using streams to create a socket server as fget does not see \0 as EOL Expected result: Expect fgets to return data at \0 Actual result: -- Nothing is returned until the buffer is filled. -- Edit this bug report at http://bugs.php.net/?id=29726&edit=1
#29500 [NEW]: Accessing object elements returns object
From: lists at cyberlot dot net Operating system: Fedora Core 2 PHP version: 5.0.0 PHP Bug Type: SimpleXML related Bug description: Accessing object elements returns object Description: When using simplexml to access a element the returned object it returns a object instead of a string Have to type cast it as a (string) to get the information back, Should not have to typecast. If a typecast is required it should be specificed in the docs. Reproduce code: --- $string = << login Richard XML; $xml = simplexml_load_string($string); print_r($xml); $login = $xml->login; print_r($login); $login = (string) $xml->login; print_r($login); Expected result: SimpleXMLElement Object ( [cmd] => login [login] => Richard ) Richard Richard Actual result: -- SimpleXMLElement Object ( [cmd] => login [login] => Richard ) SimpleXMLElement Object ( [0] => Richard ) Richard -- Edit bug report at http://bugs.php.net/?id=29500&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29500&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29500&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29500&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29500&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29500&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29500&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29500&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29500&r=support Expected behavior: http://bugs.php.net/fix.php?id=29500&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29500&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29500&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29500&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29500&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29500&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29500&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29500&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29500&r=float
#29500 [Opn]: Accessing object elements returns object
ID: 29500 User updated by: lists at cyberlot dot net Reported By: lists at cyberlot dot net Status: Open Bug Type: SimpleXML related Operating System: Fedora Core 2 PHP Version: 5.0.0 New Comment: http://us3.php.net/manual/en/ref.simplexml.php In trying to get this working I played with the examples from this page. Example 7 returns the following error Fatal error: Objects used as arrays in post/pre increment/decrement must return values by reference in /root/test.php on line 29 Previous Comments: [2004-08-03 05:15:42] lists at cyberlot dot net Description: When using simplexml to access a element the returned object it returns a object instead of a string Have to type cast it as a (string) to get the information back, Should not have to typecast. If a typecast is required it should be specificed in the docs. Reproduce code: --- $string = << login Richard XML; $xml = simplexml_load_string($string); print_r($xml); $login = $xml->login; print_r($login); $login = (string) $xml->login; print_r($login); Expected result: SimpleXMLElement Object ( [cmd] => login [login] => Richard ) Richard Richard Actual result: -- SimpleXMLElement Object ( [cmd] => login [login] => Richard ) SimpleXMLElement Object ( [0] => Richard ) Richard -- Edit this bug report at http://bugs.php.net/?id=29500&edit=1
#29500 [WFx]: Accessing object elements returns object
ID: 29500 User updated by: lists at cyberlot dot net Reported By: lists at cyberlot dot net Status: Wont fix Bug Type: SimpleXML related Operating System: Fedora Core 2 PHP Version: 5.0.0 New Comment: Im not signed up for that list... The online docs badly need updating then. 1. To express the need to use typecasting depending on how you access the variable. 2. That you can no longer "change" the simplexml object like explained in example 7 Previous Comments: [2004-08-03 12:01:13] [EMAIL PROTECTED] That's by design and was discussed on [EMAIL PROTECTED] [2004-08-03 05:23:22] lists at cyberlot dot net http://us3.php.net/manual/en/ref.simplexml.php In trying to get this working I played with the examples from this page. Example 7 returns the following error Fatal error: Objects used as arrays in post/pre increment/decrement must return values by reference in /root/test.php on line 29 [2004-08-03 05:15:42] lists at cyberlot dot net Description: When using simplexml to access a element the returned object it returns a object instead of a string Have to type cast it as a (string) to get the information back, Should not have to typecast. If a typecast is required it should be specificed in the docs. Reproduce code: --- $string = << login Richard XML; $xml = simplexml_load_string($string); print_r($xml); $login = $xml->login; print_r($login); $login = (string) $xml->login; print_r($login); Expected result: SimpleXMLElement Object ( [cmd] => login [login] => Richard ) Richard Richard Actual result: -- SimpleXMLElement Object ( [cmd] => login [login] => Richard ) SimpleXMLElement Object ( [0] => Richard ) Richard -- Edit this bug report at http://bugs.php.net/?id=29500&edit=1
#29500 [WFx]: Accessing object elements returns object
ID: 29500 User updated by: lists at cyberlot dot net Reported By: lists at cyberlot dot net Status: Wont fix Bug Type: SimpleXML related Operating System: Fedora Core 2 PHP Version: 5.0.0 New Comment: Ok it is impossible to modify the simpleobject once creating which means you can't add anything to the xml. Is this a desired affect as well? Previous Comments: [2004-08-03 15:29:03] lists at cyberlot dot net Im not signed up for that list... The online docs badly need updating then. 1. To express the need to use typecasting depending on how you access the variable. 2. That you can no longer "change" the simplexml object like explained in example 7 [2004-08-03 12:01:13] [EMAIL PROTECTED] That's by design and was discussed on [EMAIL PROTECTED] [2004-08-03 05:23:22] lists at cyberlot dot net http://us3.php.net/manual/en/ref.simplexml.php In trying to get this working I played with the examples from this page. Example 7 returns the following error Fatal error: Objects used as arrays in post/pre increment/decrement must return values by reference in /root/test.php on line 29 [2004-08-03 05:15:42] lists at cyberlot dot net Description: When using simplexml to access a element the returned object it returns a object instead of a string Have to type cast it as a (string) to get the information back, Should not have to typecast. If a typecast is required it should be specificed in the docs. Reproduce code: --- $string = << login Richard XML; $xml = simplexml_load_string($string); print_r($xml); $login = $xml->login; print_r($login); $login = (string) $xml->login; print_r($login); Expected result: SimpleXMLElement Object ( [cmd] => login [login] => Richard ) Richard Richard Actual result: -- SimpleXMLElement Object ( [cmd] => login [login] => Richard ) SimpleXMLElement Object ( [0] => Richard ) Richard -- Edit this bug report at http://bugs.php.net/?id=29500&edit=1
#48149 [NEW]: Cannot make interval parts larger than 9999.
From: lists at reptiliannature dot org
Operating system: ALL
PHP version: 5.3.0RC1
PHP Bug Type: Date/time related
Bug description: Cannot make interval parts larger than .
Description:
This bug seems to be identical to http://bugs.php.net/bug.php?id=45545
which was marked closed.
It appears than when part of the interval is greater than the
DateInterval throws an exception.
DateInterval::__construct(): Unknown or bad format (PT1M);
This happens with years, days, hours, minutes, and seconds
Reproduce code:
---
$i = 900;
while ($i) {
try {
$di = new DateInterval('PT' . $i . 'M');
}
catch (exception $e) {
var_dump($i);
echo $e->getMessage();
break;
}
$i++;
}
Expected result:
I would expect to have a DateInterval object with interval ('PT1000M') or
greater.
Actual result:
--
DateInterval::__construct(): Unknown or bad format (PT1M);
--
Edit bug report at http://bugs.php.net/?id=48149&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48149&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48149&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48149&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48149&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48149&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48149&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48149&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48149&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48149&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48149&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48149&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48149&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48149&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48149&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48149&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48149&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48149&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48149&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48149&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48149&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48149&r=mysqlcfg
#48149 [Csd]: Cannot make interval parts larger than 9999
ID: 48149
User updated by: lists at reptiliannature dot org
Reported By: lists at reptiliannature dot org
Status: Closed
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3, 6CVS (2009-05-05)
New Comment:
No problem thank you.
Previous Comments:
[2009-05-05 07:45:24] der...@php.net
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.
Hah, I had fixed it in the parser, but not ran the regenerator to the
.c file. Should be fixed in CVS now.
[2009-05-04 23:12:20] f...@php.net
Still present in 5.3.0RC2
[2009-05-04 21:20:13] lists at reptiliannature dot org
Description:
This bug seems to be identical to http://bugs.php.net/bug.php?id=45545
which was marked closed.
It appears than when part of the interval is greater than the
DateInterval throws an exception.
DateInterval::__construct(): Unknown or bad format (PT1M);
This happens with years, days, hours, minutes, and seconds
Reproduce code:
---
$i = 900;
while ($i) {
try {
$di = new DateInterval('PT' . $i . 'M');
}
catch (exception $e) {
var_dump($i);
echo $e->getMessage();
break;
}
$i++;
}
Expected result:
I would expect to have a DateInterval object with interval ('PT1000M')
or greater.
Actual result:
--
DateInterval::__construct(): Unknown or bad format (PT1M);
--
Edit this bug report at http://bugs.php.net/?id=48149&edit=1
#49674 [NEW]: spl_autoload not auto loading
From: lists at reptiliannature dot org
Operating system: Linux 2.6.28-15
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: spl_autoload not auto loading
Description:
I have been trying to use spl_autoload() to load a class located in the
same folder. My include path is set to ".". The class file exists in the
same folder, and the class has the same name as the file without the .php
extension.
The loading does not work.
Reproduce code:
---
File test.php
val.'';
?>
File ClassA.php
Expected result:
string(1) "."
Hello from class "ClassA"
Actual result:
--
string(1) "."
Fatal error: Uncaught exception 'LogicException' with message 'Class
ClassA could not be loaded' in
/home/michael/src/php/tests/spl_autoload/test.php:7
Stack trace:
#0 /home/michael/src/php/tests/spl_autoload/test.php(7):
spl_autoload('ClassA')
#1 {main}
thrown in /home/michael/src/php/tests/spl_autoload/test.php on line 7
--
Edit bug report at http://bugs.php.net/?id=49674&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49674&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49674&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49674&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49674&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49674&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49674&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49674&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49674&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49674&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49674&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49674&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49674&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49674&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49674&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49674&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49674&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49674&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49674&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49674&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49674&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49674&r=mysqlcfg
#49674 [Bgs]: spl_autoload not auto loading
ID: 49674
User updated by: lists at reptiliannature dot org
Reported By: lists at reptiliannature dot org
Status: Bogus
Bug Type: SPL related
Operating System: Linux 2.6.28-15
PHP Version: 5.3.0
New Comment:
Thanks for letting me know. I appreciate it.
Previous Comments:
[2009-09-25 21:53:01] j...@php.net
File NAME of course needs to be lowercase. Not the file contents. :D
[2009-09-25 21:52:26] j...@php.net
Class name is lowercased before any lookup is done. Hence, your file
needs to be in lowercase as well. See also bug #48129
[2009-09-25 19:35:58] lists at reptiliannature dot org
Description:
I have been trying to use spl_autoload() to load a class located in the
same folder. My include path is set to ".". The class file exists in
the same folder, and the class has the same name as the file without the
.php extension.
The loading does not work.
Reproduce code:
---
File test.php
val.'';
?>
File ClassA.php
Expected result:
string(1) "."
Hello from class "ClassA"
Actual result:
--
string(1) "."
Fatal error: Uncaught exception 'LogicException' with message 'Class
ClassA could not be loaded' in
/home/michael/src/php/tests/spl_autoload/test.php:7
Stack trace:
#0 /home/michael/src/php/tests/spl_autoload/test.php(7):
spl_autoload('ClassA')
#1 {main}
thrown in /home/michael/src/php/tests/spl_autoload/test.php on line
7
--
Edit this bug report at http://bugs.php.net/?id=49674&edit=1
#34178 [Com]: SOAP Server does not honor a method default parameter value.
ID: 34178
Comment by: lists at andyfowler dot com
Reported By: php at virtualmonet dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: redhat
PHP Version: 5.1.0b3
New Comment:
I can confirm ab at crossconcept's report.
The bug has nothing to do with SoapServer but is in WSDL-mode
SoapClient, which sets NULL for parameters which have not been
specified. Should this be resubmitted with a proper subject?
Previous Comments:
[2010-02-03 12:39:22] ab at crossconcept dot de
setClass('Test1');
$autodiscover->handle();
} else {
$soap = new Zend_Soap_Server(HOST.URL."/api.php?wsdl");
$soap->setClass('Test1');
$soap->setPersistence(SOAP_PERSISTENCE_SESSION);
$soap->handle();
}
?>
correct one, sorry for the mistake I posted. well bug still exists.
Looks like SoapClient sends NULL for parameters which were not set.
[2010-02-03 12:33:42] ab at crossconcept dot de
This bug still occurs after moren than 4 years..
setClass('Test1');
$soap->setPersistence(SOAP_PERSISTENCE_SESSION);
$soap->handle();
?>
sayhello() . "";
?>
Expected result:
sayhello to x
Actual result:
--
sayhello to
I am wondering why this was closed. Just because of the non given
""?
----
[2005-08-25 01:00:04] 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".
[2005-08-17 21:47:32] tony2...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-08-17 21:46:49] php at virtualmonet dot com
Description:
It seems PHP soap server does not set the default parameter values of
the called method.
#===
Line 1 should return "sayhello to x"
but instead returns "sayhello to"
Reproduce code:
---
#--
# on the server side
class Test1 {
/**
*
* @param string $me
* @return string
*/
function sayHello($me='x'){
$s = "sayhello to $me";
return $s;
}
}
#--
# on the client side
$o=new SoapClient($url);
echo $o->sayhello() . "";
Expected result:
sayhello to x
Actual result:
--
sayhello to
--
Edit this bug report at http://bugs.php.net/?id=34178&edit=1
#35026 [NEW]: fwrite to socket stream no longer working as expected
From: lists at cyberlot dot net Operating system: Fedora Core 3 PHP version: 5.1.0RC4 PHP Bug Type: Network related Bug description: fwrite to socket stream no longer working as expected Description: I have tried running both the socket server and the socket test script on multiple versions found the only part that matters is what version the server is running on. On RC1 it works fine, RC3 and RC4 ( never tried RC2 ) some of the writes get "lost" Reproduce code: --- http://www.flashunity.com/wiki/DownLoads Run the engine.php in one terminal, runtests.php in other.. RC1 everything works RC3 and RC4 the tests never finish, Mine always hang on the 3rd test. I haven't been able to reproduce with a simpler set of code as of yet. Expected result: Tests to be completed Actual result: -- Tests fail -- Edit bug report at http://bugs.php.net/?id=35026&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35026&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35026&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35026&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35026&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35026&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35026&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35026&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35026&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35026&r=support Expected behavior: http://bugs.php.net/fix.php?id=35026&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35026&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35026&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35026&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35026&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35026&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35026&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35026&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35026&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35026&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35026&r=mysqlcfg
#35026 [Fbk->Csd]: fwrite to socket stream no longer working as expected
ID: 35026
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Feedback
+Status: Closed
Bug Type: Network related
Operating System: Fedora Core 3
PHP Version: 5.1.0RC4
New Comment:
I am sorry, I assumed this to be a socket issue when in reality it
turned out to be a simple_xml issue
It is possible for a simpleXMLElemnt Object to fail a
if($object) {
}
Test in RC3 and RC4 will resubmit as new bug
Previous Comments:
[2005-10-30 18:19:08] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
A SHORT reproduce script is required 10-20 lines.
[2005-10-30 18:07:28] lists at cyberlot dot net
Description:
I have tried running both the socket server and the socket test script
on multiple versions found the only part that matters is what version
the server is running on.
On RC1 it works fine, RC3 and RC4 ( never tried RC2 ) some of the
writes get "lost"
Reproduce code:
---
http://www.flashunity.com/wiki/DownLoads
Run the engine.php in one terminal, runtests.php in other.. RC1
everything works RC3 and RC4 the tests never finish, Mine always hang
on the 3rd test.
I haven't been able to reproduce with a simpler set of code as of yet.
Expected result:
Tests to be completed
Actual result:
--
Tests fail
--
Edit this bug report at http://bugs.php.net/?id=35026&edit=1
#35028 [NEW]: XML object fails FALSE test
From: lists at cyberlot dot net
Operating system: Fedore Core 3
PHP version: 5.1.0RC4
PHP Bug Type: SimpleXML related
Bug description: XML object fails FALSE test
Description:
$xml object returns false, this worked in RC1 fails in RC3 and RC4 never
tested RC2
xml string of test DOES pass test. Its only when you have
subchildren children that the $xml object fails to pass.
test fails
test Passes.
if(is_object($xml)) { works, and is prob the best method to use but one
would expect $xml to be "true"
Realize this might be considered a dupe of bug #31045 however bug #34199
suggests the same issue that states this is fixed.
Reproduce code:
---
kklklk";
$xml = simplexml_load_String($string);
if($xml) {
echo "Passed test\n";
} else {
echo "Even though is object still failed false test\n";
}
?>
Expected result:
Expect output of Passed test
Actual result:
--
output of Even though is object still failed false test
--
Edit bug report at http://bugs.php.net/?id=35028&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35028&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35028&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35028&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35028&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35028&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35028&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35028&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35028&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35028&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35028&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35028&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35028&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35028&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35028&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35028&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35028&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35028&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35028&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35028&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35028&r=mysqlcfg
#35202 [NEW]: errorCode() Returns String
From: lists at zaunere dot com
Operating system: Windows XP
PHP version: 5.1.0RC4
PHP Bug Type: PDO related
Bug description: errorCode() Returns String
Description:
The errorCode() method of both the PDO and PDOStatement objects return a
string, rather than an integer, as documented. If there is no error, they
return an empty string.
Reproduce code:
---
$stmt = $MyPDO->prepare('SELECT * FROM MyTable');
var_dump($stmt->errorCode());
Expected result:
int(0)
Actual result:
--
string(0) ""
--
Edit bug report at http://bugs.php.net/?id=35202&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35202&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35202&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35202&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35202&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35202&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35202&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35202&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35202&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35202&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35202&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35202&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35202&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35202&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35202&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35202&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35202&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35202&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35202&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35202&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35202&r=mysqlcfg
#35202 [Bgs->Opn]: errorCode() Returns String
ID: 35202
User updated by: lists at zaunere dot com
Reported By: lists at zaunere dot com
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0RC4
Assigned To: wez
New Comment:
The function prototypes in both of these locations is wrong:
http://us2.php.net/manual/en/function.pdo-errorcode.php
http://us2.php.net/manual/en/function.pdostatement-errorcode.php
Integers are not returned as indicated in the documented function
prototypes.
Furthermore, there is some inconsistency in how '0' is returned.
It would be expected that '0' is always returned, or that an
invalid statement prepare would return an error.
Code
$pdo = new PDO('mysql:dbname=oet;host=localhost','me','you');
echo 'new pdo (good connection)=> ';
var_dump($pdo->errorCode());
$stmt = $pdo->prepare('SELECT * FROM Valid');
echo ' stmt prepare (valid table)=> ';
var_dump($stmt->errorCode());
$stmt->execute();
echo ' stmt execute (valid table)=> ';
var_dump($stmt->errorCode());
$stmt1 = $pdo->prepare('SELECT * FROM Invalid');
echo 'stmt1 prepare (invalid table)=> ';
var_dump($stmt1->errorCode());
$stmt1->execute();
echo 'stmt1 execute (invalid table)=> ';
var_dump($stmt1->errorCode());
$stmt2 = $pdo->prepare('INVALID SQL');
echo ' stmt2 prepare (invalid SQL)=> ';
var_dump($stmt2->errorCode());
$stmt2->execute();
echo ' stmt2 execute (invalid SQL)=> ';
var_dump($stmt2->errorCode());
Output
--
new pdo (good connection)=> string(5) "0"
stmt prepare (valid table)=> string(0) ""
stmt execute (valid table)=> string(5) "0"
stmt1 prepare (invalid table)=> string(0) ""
stmt1 execute (invalid table)=> string(5) "HY000"
stmt2 prepare (invalid SQL)=> string(0) ""
stmt2 execute (invalid SQL)=> string(5) "HY000"
Only the execute() appears to set errorCode(), whereas the documents
say "the last operation on the statement handle."
Thanks,
Hans
Previous Comments:
[2005-11-13 13:37:14] [EMAIL PROTECTED]
errorCode() returns a SQLSTATE string, as documented.
Use errorInfo() to obtain driver specific error information.
[2005-11-12 20:13:41] [EMAIL PROTECTED]
SQL error codes are strings
[2005-11-12 20:11:20] lists at zaunere dot com
Description:
The errorCode() method of both the PDO and PDOStatement objects return
a string, rather than an integer, as documented. If there is no error,
they return an empty string.
Reproduce code:
---
$stmt = $MyPDO->prepare('SELECT * FROM MyTable');
var_dump($stmt->errorCode());
Expected result:
int(0)
Actual result:
--
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=35202&edit=1
#35368 [NEW]: PDO query does not work properly with serialize
From: lists at cyberlot dot net
Operating system: Centos 4.1
PHP version: 6CVS-2005-11-24 (snap)
PHP Bug Type: PDO related
Bug description: PDO query does not work properly with serialize
Description:
If you serialize a string, and run any of the escape functions,
mysql_escape, addslashes you can not use pdo->query to insert and it does
some sort of bind params translation on the string.
Bug exists in php5.1RC4 as I was using that version when I first found
this and upgraded to see if issue was resolved.
Using prepared statements ( and therefore not having to escape the data
before hand ) works.
Reproduce code:
---
\n";
$var = mysql_escape_string($var);
$query = "INSERT INTO sessions SET value = '$var'";
$db->query($query);
$query = 'SELECT value FROM sessions';
$result = $db->query($query);
$row = $result->fetch();
echo $row[0]."\n\n";
?>
Expected result:
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
Actual result:
--
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
--
Edit bug report at http://bugs.php.net/?id=35368&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35368&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35368&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35368&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35368&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35368&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35368&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35368&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35368&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35368&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35368&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35368&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35368&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35368&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35368&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35368&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35368&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35368&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35368&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35368&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35368&r=mysqlcfg
#35368 [Asn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Assigned
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
I tried the same thing using prepare/bind/execute and it does insert
the serialized/escaped string properly with the slashes as expected so
this is limited to a issue with the pdo->query
Previous Comments:
[2005-11-24 16:19:25] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-24 16:07:36] lists at cyberlot dot net
Description:
If you serialize a string, and run any of the escape functions,
mysql_escape, addslashes you can not use pdo->query to insert and it
does some sort of bind params translation on the string.
Bug exists in php5.1RC4 as I was using that version when I first found
this and upgraded to see if issue was resolved.
Using prepared statements ( and therefore not having to escape the data
before hand ) works.
Reproduce code:
---
\n";
$var = mysql_escape_string($var);
$query = "INSERT INTO sessions SET value = '$var'";
$db->query($query);
$query = 'SELECT value FROM sessions';
$result = $db->query($query);
$row = $result->fetch();
echo $row[0]."\n\n";
?>
Expected result:
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
Actual result:
--
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Asn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Assigned
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Recompiled from
--with-pdo --with-mysql
to
--with-pdo --with-mysqli
Still the same issue so its within pdo itself and not some weird
interaction between pdo and mysql library
Previous Comments:
[2005-11-24 16:29:41] lists at cyberlot dot net
I tried the same thing using prepare/bind/execute and it does insert
the serialized/escaped string properly with the slashes as expected so
this is limited to a issue with the pdo->query
[2005-11-24 16:19:25] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-24 16:07:36] lists at cyberlot dot net
Description:
If you serialize a string, and run any of the escape functions,
mysql_escape, addslashes you can not use pdo->query to insert and it
does some sort of bind params translation on the string.
Bug exists in php5.1RC4 as I was using that version when I first found
this and upgraded to see if issue was resolved.
Using prepared statements ( and therefore not having to escape the data
before hand ) works.
Reproduce code:
---
\n";
$var = mysql_escape_string($var);
$query = "INSERT INTO sessions SET value = '$var'";
$db->query($query);
$query = 'SELECT value FROM sessions';
$result = $db->query($query);
$row = $result->fetch();
echo $row[0]."\n\n";
?>
Expected result:
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
Actual result:
--
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Asn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Assigned
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Also tried with sqlite, did not get the same issue.
Previous Comments:
[2005-11-24 16:46:13] lists at cyberlot dot net
Recompiled from
--with-pdo --with-mysql
to
--with-pdo --with-mysqli
Still the same issue so its within pdo itself and not some weird
interaction between pdo and mysql library
[2005-11-24 16:29:41] lists at cyberlot dot net
I tried the same thing using prepare/bind/execute and it does insert
the serialized/escaped string properly with the slashes as expected so
this is limited to a issue with the pdo->query
[2005-11-24 16:19:25] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-24 16:07:36] lists at cyberlot dot net
Description:
If you serialize a string, and run any of the escape functions,
mysql_escape, addslashes you can not use pdo->query to insert and it
does some sort of bind params translation on the string.
Bug exists in php5.1RC4 as I was using that version when I first found
this and upgraded to see if issue was resolved.
Using prepared statements ( and therefore not having to escape the data
before hand ) works.
Reproduce code:
---
\n";
$var = mysql_escape_string($var);
$query = "INSERT INTO sessions SET value = '$var'";
$db->query($query);
$query = 'SELECT value FROM sessions';
$result = $db->query($query);
$row = $result->fetch();
echo $row[0]."\n\n";
?>
Expected result:
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
Actual result:
--
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Asn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Assigned
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
pdo->quote does not solve the problem either
Previous Comments:
[2005-11-24 17:02:43] lists at cyberlot dot net
Also tried with sqlite, did not get the same issue.
[2005-11-24 16:46:13] lists at cyberlot dot net
Recompiled from
--with-pdo --with-mysql
to
--with-pdo --with-mysqli
Still the same issue so its within pdo itself and not some weird
interaction between pdo and mysql library
[2005-11-24 16:29:41] lists at cyberlot dot net
I tried the same thing using prepare/bind/execute and it does insert
the serialized/escaped string properly with the slashes as expected so
this is limited to a issue with the pdo->query
[2005-11-24 16:19:25] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-24 16:07:36] lists at cyberlot dot net
Description:
If you serialize a string, and run any of the escape functions,
mysql_escape, addslashes you can not use pdo->query to insert and it
does some sort of bind params translation on the string.
Bug exists in php5.1RC4 as I was using that version when I first found
this and upgraded to see if issue was resolved.
Using prepared statements ( and therefore not having to escape the data
before hand ) works.
Reproduce code:
---
\n";
$var = mysql_escape_string($var);
$query = "INSERT INTO sessions SET value = '$var'";
$db->query($query);
$query = 'SELECT value FROM sessions';
$result = $db->query($query);
$row = $result->fetch();
echo $row[0]."\n\n";
?>
Expected result:
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
Actual result:
--
[EMAIL PROTECTED] www_admin]# php index.php
a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Fbk->Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Ok I narrowed down the exact issue, It has to do with use of ' vs the
use of "
SET value = 'serializedandescapedstring' -- BAD converts string as
mentioned
SET value = "serializedandescapedstring" -- Works
pdo->quote quotes the string for you by putting "" around it so it
works, If you try to quote yourself with '' you get my weird results.
Now that I know exactly whats going on its pretty easy to work around,
but could catch people off guard.
Previous Comments:
[2005-11-24 20:12:05] [EMAIL PROTECTED]
Don't use HEAD, use PHP 5.1.
Which version of mysql are you using?
The following script works fine for me:
$db = new PDO('mysql:dbname=test;host=localhost', 'root', '');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$var =
'a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}';
$qvar = $db->quote($var);
$query = "INSERT INTO sessions SET value = $qvar";
//$q = $db->prepare($query);
//$q->execute();
$q = $db->query($query);
$q->debugDumpParams();
[2005-11-24 17:12:04] lists at cyberlot dot net
pdo->quote does not solve the problem either
[2005-11-24 17:02:43] lists at cyberlot dot net
Also tried with sqlite, did not get the same issue.
[2005-11-24 16:46:13] lists at cyberlot dot net
Recompiled from
--with-pdo --with-mysql
to
--with-pdo --with-mysqli
Still the same issue so its within pdo itself and not some weird
interaction between pdo and mysql library
[2005-11-24 16:29:41] lists at cyberlot dot net
I tried the same thing using prepare/bind/execute and it does insert
the serialized/escaped string properly with the slashes as expected so
this is limited to a issue with the pdo->query
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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Fbk->Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Debug output
SQL: [116] INSERT INTO sessions SET value =
'a:1:{s:4:\"test\";a:2:{s:5:\"test2\";s:4:\"1234\";s:5:\"test3\";s:6:\"555353\";}}'
Params: 0
Value in mysql after this
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
I downloaded the release version of php 5.1 and reran same results
Previous Comments:
[2005-11-24 23:28:31] [EMAIL PROTECTED]
I still want to see the debugDumpParams() output in the case where it
breaks.
[2005-11-24 23:24:34] lists at cyberlot dot net
Ok I narrowed down the exact issue, It has to do with use of ' vs the
use of "
SET value = 'serializedandescapedstring' -- BAD converts string as
mentioned
SET value = "serializedandescapedstring" -- Works
pdo->quote quotes the string for you by putting "" around it so it
works, If you try to quote yourself with '' you get my weird results.
Now that I know exactly whats going on its pretty easy to work around,
but could catch people off guard.
[2005-11-24 20:12:05] [EMAIL PROTECTED]
Don't use HEAD, use PHP 5.1.
Which version of mysql are you using?
The following script works fine for me:
$db = new PDO('mysql:dbname=test;host=localhost', 'root', '');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$var =
'a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}';
$qvar = $db->quote($var);
$query = "INSERT INTO sessions SET value = $qvar";
//$q = $db->prepare($query);
//$q->execute();
$q = $db->query($query);
$q->debugDumpParams();
[2005-11-24 17:12:04] lists at cyberlot dot net
pdo->quote does not solve the problem either
[2005-11-24 17:02:43] lists at cyberlot dot net
Also tried with sqlite, did not get the same 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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Fbk->Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Mysql 5.0.15
I have a few other systems I can see if I can try to replicate on
Previous Comments:
[2005-11-25 05:07:42] [EMAIL PROTECTED]
I can't reproduce this at all, even disabling native prepared statement
support in mysql doesn't give me those results.
Which version of mysql are you using?
[2005-11-25 01:03:16] lists at cyberlot dot net
Debug output
SQL: [116] INSERT INTO sessions SET value =
'a:1:{s:4:\"test\";a:2:{s:5:\"test2\";s:4:\"1234\";s:5:\"test3\";s:6:\"555353\";}}'
Params: 0
Value in mysql after this
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
I downloaded the release version of php 5.1 and reran same results
[2005-11-24 23:28:31] [EMAIL PROTECTED]
I still want to see the debugDumpParams() output in the case where it
breaks.
[2005-11-24 23:24:34] lists at cyberlot dot net
Ok I narrowed down the exact issue, It has to do with use of ' vs the
use of "
SET value = 'serializedandescapedstring' -- BAD converts string as
mentioned
SET value = "serializedandescapedstring" -- Works
pdo->quote quotes the string for you by putting "" around it so it
works, If you try to quote yourself with '' you get my weird results.
Now that I know exactly whats going on its pretty easy to work around,
but could catch people off guard.
[2005-11-24 20:12:05] [EMAIL PROTECTED]
Don't use HEAD, use PHP 5.1.
Which version of mysql are you using?
The following script works fine for me:
$db = new PDO('mysql:dbname=test;host=localhost', 'root', '');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$var =
'a:1:{s:4:"test";a:2:{s:5:"test2";s:4:"1234";s:5:"test3";s:6:"555353";}}';
$qvar = $db->quote($var);
$query = "INSERT INTO sessions SET value = $qvar";
//$q = $db->prepare($query);
//$q->execute();
$q = $db->query($query);
$q->debugDumpParams();
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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results
Previous Comments:
[2005-11-25 15:00:01] lists at cyberlot dot net
Mysql 5.0.15
I have a few other systems I can see if I can try to replicate on
[2005-11-25 05:07:42] [EMAIL PROTECTED]
I can't reproduce this at all, even disabling native prepared statement
support in mysql doesn't give me those results.
Which version of mysql are you using?
[2005-11-25 01:03:16] lists at cyberlot dot net
Debug output
SQL: [116] INSERT INTO sessions SET value =
'a:1:{s:4:\"test\";a:2:{s:5:\"test2\";s:4:\"1234\";s:5:\"test3\";s:6:\"555353\";}}'
Params: 0
Value in mysql after this
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
I downloaded the release version of php 5.1 and reran same results
[2005-11-24 23:28:31] [EMAIL PROTECTED]
I still want to see the debugDumpParams() output in the case where it
breaks.
[2005-11-24 23:24:34] lists at cyberlot dot net
Ok I narrowed down the exact issue, It has to do with use of ' vs the
use of "
SET value = 'serializedandescapedstring' -- BAD converts string as
mentioned
SET value = "serializedandescapedstring" -- Works
pdo->quote quotes the string for you by putting "" around it so it
works, If you try to quote yourself with '' you get my weird results.
Now that I know exactly whats going on its pretty easy to work around,
but could catch people off guard.
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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
What OS are you testing on? All I have are Centos/Redhat based boxes to
test on.
Also if this helps I always download directly from MySQL I never use
the DIST included rpms.
Previous Comments:
[2005-11-25 15:11:22] lists at cyberlot dot net
Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results
[2005-11-25 15:00:01] lists at cyberlot dot net
Mysql 5.0.15
I have a few other systems I can see if I can try to replicate on
[2005-11-25 05:07:42] [EMAIL PROTECTED]
I can't reproduce this at all, even disabling native prepared statement
support in mysql doesn't give me those results.
Which version of mysql are you using?
[2005-11-25 01:03:16] lists at cyberlot dot net
Debug output
SQL: [116] INSERT INTO sessions SET value =
'a:1:{s:4:\"test\";a:2:{s:5:\"test2\";s:4:\"1234\";s:5:\"test3\";s:6:\"555353\";}}'
Params: 0
Value in mysql after this
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
I downloaded the release version of php 5.1 and reran same results
[2005-11-24 23:28:31] [EMAIL PROTECTED]
I still want to see the debugDumpParams() output in the case where it
breaks.
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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Opn]: PDO query does not work properly with serialize
ID: 35368
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Open
Bug Type: PDO related
Operating System: Centos 4.1
PHP Version: 6CVS-2005-11-24 (snap)
Assigned To: wez
New Comment:
Also for note, In both cases pdo suport was configured in, not
installed by pear.
Previous Comments:
[2005-11-25 15:14:33] lists at cyberlot dot net
What OS are you testing on? All I have are Centos/Redhat based boxes to
test on.
Also if this helps I always download directly from MySQL I never use
the DIST included rpms.
[2005-11-25 15:11:22] lists at cyberlot dot net
Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results
[2005-11-25 15:00:01] lists at cyberlot dot net
Mysql 5.0.15
I have a few other systems I can see if I can try to replicate on
[2005-11-25 05:07:42] [EMAIL PROTECTED]
I can't reproduce this at all, even disabling native prepared statement
support in mysql doesn't give me those results.
Which version of mysql are you using?
[2005-11-25 01:03:16] lists at cyberlot dot net
Debug output
SQL: [116] INSERT INTO sessions SET value =
'a:1:{s:4:\"test\";a:2:{s:5:\"test2\";s:4:\"1234\";s:5:\"test3\";s:6:\"555353\";}}'
Params: 0
Value in mysql after this
a?:{s?:"test";a?:{s?:"test2";s?:"1234";s?:"test3";s?:"555353";}}
I downloaded the release version of php 5.1 and reran same results
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/35368
--
Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Opn]: PDO query does not work properly with serialize
ID: 35368 User updated by: lists at cyberlot dot net Reported By: lists at cyberlot dot net Status: Open Bug Type: PDO related Operating System: Centos 4.1 PHP Version: 6CVS-2005-11-24 (snap) Assigned To: wez New Comment: To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? Previous Comments: [2005-11-25 15:16:27] lists at cyberlot dot net Also for note, In both cases pdo suport was configured in, not installed by pear. [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. [2005-11-25 15:11:22] lists at cyberlot dot net Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results [2005-11-25 15:00:01] lists at cyberlot dot net Mysql 5.0.15 I have a few other systems I can see if I can try to replicate on [2005-11-25 05:07:42] [EMAIL PROTECTED] I can't reproduce this at all, even disabling native prepared statement support in mysql doesn't give me those results. Which version of mysql are you using? 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#40244 [NEW]: PHP Strict errors even with E_STRICT Disabled
From: lists at cyberlot dot net
Operating system: Centos 4.4
PHP version: 5.2.0
PHP Bug Type: Compile Warning
Bug description: PHP Strict errors even with E_STRICT Disabled
Description:
Description:
This is during the user of Net_SMTP and Mail but the bugs come from the
user of is_a in PEAR And non-static method calls to PEAR::isError()
error_reporting(0) not working as expected within pear
Test script:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Reproduce code:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Expected result:
nothing error reporting is turned off before code, turned back on after
code
Actual result:
--
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 331
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 169
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 334
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 337
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
--
Edit bug report at http://bugs.php.net/?id=40244&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40244&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40244&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40244&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40244&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40244&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40244&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40244&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40244&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40244&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40244&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40244&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40244&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40244&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40244&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40244&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40244&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40244&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40244&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40244&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40244&r=mysqlcfg
#40244 [Opn]: PHP Strict errors even with E_STRICT Disabled
ID: 40244
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Open
Bug Type: Compile Warning
Operating System: Centos 4.4
PHP Version: 5.2.0
New Comment:
Happens in the newest RC4 release as well
Previous Comments:
[2007-01-26 01:11:24] lists at cyberlot dot net
Description:
Description:
This is during the user of Net_SMTP and Mail but the bugs come from
the
user of is_a in PEAR And non-static method calls to PEAR::isError()
error_reporting(0) not working as expected within pear
Test script:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Reproduce code:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Expected result:
nothing error reporting is turned off before code, turned back on
after
code
Actual result:
--
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 331
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 169
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 334
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 337
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
--
Edit this bug report at http://bugs.php.net/?id=40244&edit=1
#40244 [Opn]: PHP Strict errors even with E_STRICT Disabled
ID: 40244
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Open
Bug Type: Compile Warning
Operating System: Centos 4.4
PHP Version: 5.2.0
New Comment:
also if you remove the error_reporting($er); the error goes away, even
though that line is after all the other php code.
Previous Comments:
[2007-01-26 01:26:01] lists at cyberlot dot net
Happens in the newest RC4 release as well
[2007-01-26 01:11:24] lists at cyberlot dot net
Description:
Description:
This is during the user of Net_SMTP and Mail but the bugs come from
the
user of is_a in PEAR And non-static method calls to PEAR::isError()
error_reporting(0) not working as expected within pear
Test script:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Reproduce code:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Expected result:
nothing error reporting is turned off before code, turned back on
after
code
Actual result:
--
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 331
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 169
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 334
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 337
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
--
Edit this bug report at http://bugs.php.net/?id=40244&edit=1
#40244 [Bgs->Opn]: PHP Strict errors even with E_STRICT Disabled
ID: 40244
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Bogus
+Status: Open
Bug Type: Compile Warning
Operating System: Centos 4.4
PHP Version: 5.2.0
New Comment:
They told me to report it to you
http://pear.php.net/bugs/bug.php?id=9950
So the 2 "teams" need to get together and figure this out one way or
the other.
Since this has to do directly with error reporting not disabling
warnings, not with the fact that there are warnings I would tend to
lean towards the php side of things
Previous Comments:
[2007-01-26 09:00:14] [EMAIL PROTECTED]
Please report PEAR issues to PEAR people using PEAR bug tracker:
http://pear.php.net
Thank you.
[2007-01-26 01:27:43] lists at cyberlot dot net
also if you remove the error_reporting($er); the error goes away, even
though that line is after all the other php code.
[2007-01-26 01:26:01] lists at cyberlot dot net
Happens in the newest RC4 release as well
[2007-01-26 01:11:24] lists at cyberlot dot net
Description:
Description:
This is during the user of Net_SMTP and Mail but the bugs come from
the
user of is_a in PEAR And non-static method calls to PEAR::isError()
error_reporting(0) not working as expected within pear
Test script:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Reproduce code:
---
send('[EMAIL PROTECTED]','Subject','Body');
error_reporting($er);
?>
Expected result:
nothing error reporting is turned off before code, turned back on
after
code
Actual result:
--
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 331
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 169
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 334
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
PHP Strict Standards: Non-static method PEAR::isError() should not be
called statically, assuming $this from incompatible context in
/usr/local/lib/php/Net/SMTP.php on line 337
PHP Strict Standards: is_a(): Deprecated. Please use the instanceof
operator in /usr/local/lib/php/PEAR.php on line 281
--
Edit this bug report at http://bugs.php.net/?id=40244&edit=1
#40244 [Bgs->Opn]: PHP Strict errors even with E_STRICT Disabled
ID: 40244
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
-Status: Bogus
+Status: Open
Bug Type: Compile Warning
Operating System: Centos 4.4
PHP Version: 5.2.0
New Comment:
Your wrong, Try the following
send('[EMAIL PROTECTED]','Subject','Body');
?>
If these errors are during compile time, and compile time happens
before all this then why does the above code not report the errors?
Previous Comments:
[2007-01-26 15:11:33] [EMAIL PROTECTED]
These messages are generated in compile time, all the functions are
executed AFTER that, so error_reporting(0); does not have any effect
and this is expected behaviour.
----
[2007-01-26 15:04:08] lists at cyberlot dot net
They told me to report it to you
http://pear.php.net/bugs/bug.php?id=9950
So the 2 "teams" need to get together and figure this out one way or
the other.
Since this has to do directly with error reporting not disabling
warnings, not with the fact that there are warnings I would tend to
lean towards the php side of things
[2007-01-26 09:00:14] [EMAIL PROTECTED]
Please report PEAR issues to PEAR people using PEAR bug tracker:
http://pear.php.net
Thank you.
----
[2007-01-26 01:27:43] lists at cyberlot dot net
also if you remove the error_reporting($er); the error goes away, even
though that line is after all the other php code.
----
[2007-01-26 01:26:01] lists at cyberlot dot net
Happens in the newest RC4 release as well
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/40244
--
Edit this bug report at http://bugs.php.net/?id=40244&edit=1
#40244 [Bgs]: PHP Strict errors even with E_STRICT Disabled
ID: 40244
User updated by: lists at cyberlot dot net
Reported By: lists at cyberlot dot net
Status: Bogus
Bug Type: Compile Warning
Operating System: Centos 4.4
PHP Version: 5.2.0
New Comment:
Thank you Tony for taking some time to look into this, whats happening
makes a lot more sense now.
Previous Comments:
[2007-01-26 15:23:56] [EMAIL PROTECTED]
I was wrong, these PEAR classes register some shutdown function, which
generates those warnings and the second call to error_reporting()
enables them.
Still pretty much expected.
[2007-01-26 15:23:01] lists at cyberlot dot net
Your wrong, Try the following
send('[EMAIL PROTECTED]','Subject','Body');
?>
If these errors are during compile time, and compile time happens
before all this then why does the above code not report the errors?
[2007-01-26 15:11:33] [EMAIL PROTECTED]
These messages are generated in compile time, all the functions are
executed AFTER that, so error_reporting(0); does not have any effect
and this is expected behaviour.
----
[2007-01-26 15:04:08] lists at cyberlot dot net
They told me to report it to you
http://pear.php.net/bugs/bug.php?id=9950
So the 2 "teams" need to get together and figure this out one way or
the other.
Since this has to do directly with error reporting not disabling
warnings, not with the fact that there are warnings I would tend to
lean towards the php side of things
[2007-01-26 09:00:14] [EMAIL PROTECTED]
Please report PEAR issues to PEAR people using PEAR bug tracker:
http://pear.php.net
Thank you.
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/40244
--
Edit this bug report at http://bugs.php.net/?id=40244&edit=1
#34895 [Com]: headers_list functionality regression
ID: 34895
Comment by: lists at fairsky dot us
Reported By: alex at weej dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: GNU Linux
PHP Version: 5.0.5
New Comment:
I've been looking through the CVS, and there has been only the very
slightest change to headers_list since it was introduced, so I don't
think it ever worked the way we want. I was going to try to patch my
PHP source to make headers_list include the entire header, but so far
it looks to me like it already should, so I'm obviously missing
something.
If anyone knows enough to suggest a patch it would be useful to me even
if it doesn't become official.
Previous Comments:
[2006-01-24 18:06:27] alex at weej dot com
Still looking for a replacement function. Any ideas?
[2005-10-27 17:00:09] alex at weej dot com
The documentation has been updated now.
Is there going to be a replacement function in the very near future? I
need this for a caching problem!
[2005-10-17 18:39:08] alex at weej dot com
Description:
The documented behaviour is exactly what I need for a project I am
working on, but now the behaviour has changed (even though the docs
haven't yet). :(
As far as I can see, there is no way to tell what headers PHP is
sending and their values, now.
apache_response_headers() is /not/ a replacement, as it omits
Content-Type (the most important header in my situation) and processes
the headers PHP passes to it. I really don't want to resort to wrapper
functions to maintain my own list. The documentation describes EXACTLY
the functionality I want.
I am upset! :(
http://uk.php.net/manual/en/function.headers-list.php
Reproduce code:
---
Expected result:
array(4) {
[0]=>
string(29) "X-Powered-By: PHP/5.0.0"
[1]=>
string(19) "Set-Cookie: foo=bar"
[2]=>
string(18) "X-Sample-Test: foo"
[3]=>
string(24) "Content-type: text/plain"
}
Actual result:
--
array(4) {
[0]=>
string(12) "X-Powered-By"
[1]=>
string(10) "Set-Cookie"
[2]=>
string(13) "X-Sample-Test"
[3]=>
string(12) "Content-Type"
}
--
Edit this bug report at http://bugs.php.net/?id=34895&edit=1
#36613 [NEW]: array_slice Cannot Preserve Keys without Length
From: lists at zaunere dot com
Operating system: Windows
PHP version: 5.1.2
PHP Bug Type: Feature/Change Request
Bug description: array_slice Cannot Preserve Keys without Length
Description:
The optional fourth parameter preserve_keys is only available if the third
parameter length is also supplied. If the developer wishes to set
preserve_keys to TRUE, he must also supply the length of the array he
wishes to have returned, which may not be known.
There is no way to indicate that length should remain optional - like
passing NULL - while providing a value for preserve_keys.
Reproduce code:
---
$SomeArray = array('First','Middle','Last');
var_dump(array_slice($SomeArray,1,NULL,TRUE));
Expected result:
array(2) {
[1]=>
string(6) "Middle"
[2]=>
string(4) "Last"
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=36613&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36613&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36613&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36613&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36613&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36613&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36613&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36613&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36613&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36613&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36613&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36613&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36613&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36613&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36613&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36613&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36613&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36613&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36613&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36613&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36613&r=mysqlcfg
#33970 [NEW]: Seg fault when error should be returned
From: lists at cyberlot dot net
Operating system: Fedora Core 3
PHP version: 5.1.0b3
PHP Bug Type: PDO related
Bug description: Seg fault when error should be returned
Description:
Running this script seg faults instead of producing a reasonable error.
Reproduce code:
---
$dsn = "mysql:dbname=123;host=localhost";
$dbuser = "123";
$dbpass = "123";
class PDO_Dynamic extends PDO {
private $dsn;
private $dbuser;
private $dbpass;
function PDO_Dynamic($dsn, $dbuser, $dbpass) {
$this->dsn = $dsn;
$this->dbuser = $dbuser;
$this->dbpass = $dbpass;
$temp = $this->PDO($dsn, $dbuser, $dbpass);
}
}
$db_read = new PDO_Dynamic($dsn, $dbuser, $dbpass);
$db_write = new PDO_Dynamic($dsn, $dbuser, $dbpass.'-');
Expected result:
No error at all expected, or at least some sort of warning/fault
Actual result:
--
#0 0x08130533 in pdo_hash_methods (dbh=0x9e189b4, kind=0) at
/root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:990
#1 0x081308bf in dbh_method_get (object_pp=0xbffb5294,
method_name=0x9e1baa4 "PDO", method_len=3) at
/root/sources/php-5.1.0b3/ext/pdo/pdo_dbh.c:1065
#2 0x0833f150 in ZEND_INIT_METHOD_CALL_SPEC_UNUSED_CONST_HANDLER
(execute_data=0xbffb5270) at zend_vm_execute.h:14663
#3 0x08317eeb in execute (op_array=0x9e1b52c) at zend_vm_execute.h:87
#4 0x0831835b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbffb54a0) at zend_vm_execute.h:213
#5 0x08318a73 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbffb54a0) at zend_vm_execute.h:299
#6 0x08317eeb in execute (op_array=0x9e140ac) at zend_vm_execute.h:87
#7 0x082f19f9 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /root/sources/php-5.1.0b3/Zend/zend.c:1087
#8 0x082b0a9d in php_execute_script (primary_file=0xbffb78d0) at
/root/sources/php-5.1.0b3/main/main.c:1672
#9 0x0835ce9b in main (argc=2, argv=0xbffb79a4) at
/root/sources/php-5.1.0b3/sapi/cli/php_cli.c:1039
--
Edit bug report at http://bugs.php.net/?id=33970&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33970&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33970&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33970&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33970&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33970&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33970&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33970&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33970&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33970&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33970&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33970&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33970&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33970&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33970&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33970&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33970&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33970&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33970&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33970&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33970&r=mysqlcfg
#30188 [Bgs->Opn]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
No, you're simply WRONG:
"->All symbolic
links are resolved, so it's not possible to avoid this restriction
with
a symlink.<-"
because my open_basedir is set to:
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"
therefore the file lies in basedir either way, when I call:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
It's a bug and I would expect someone with email "@php.net" to at least
READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over
and over again, because you simply assume from beginning that I'm wrong
(and the only action you do is actually telling me bullshit about
RTFM).
I did RTFM, but your implementation simply doesn't correspond with the
things written in TFM.
[offensive]
Anyway, I don't care about PHP anymore - I have better things to do
than pushing you to at least read what you're responding to ... btw,
responding to bugreports after 2 months is really, really wonderful.
Better than never, though.
[/offensive]
Previous Comments:
[2004-11-28 15:16:38] [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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
[2004-09-21 23:50:28] lists+php at box dot cz
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in various filesystem functions)?
Btw, this problem exists also in 4.3.8, which makes me think that it's
there for a LONG time ... unnoticed.
W.
Reproduce code:
---
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');
Expected result:
-
#30188 [Bgs->Csd]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Closed
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
My final words would be:
Function, that does basedir check differently based on (non)existence
of the file (which is) being checked, is flawed.
I'm putting my hands off it ... to ensure your precious time won't be
wasted. After all -1 happy_user/advocate means nothing compared to
solving real issues like adding more entropy to PHP sources or changing
parameter passing again ;-)
Btw, this attitude kinda reminds me "don't live with broken windows"
from "The Pragmatic Programmer" (and if you don't know what that means,
all the more reason not to mess with this [in your opinion absolutely
correct] behaviour of basedir check).
Luckily enough there's enough alternatives to this whole PHP thing.
Previous Comments:
[2004-11-28 17:28:15] [EMAIL PROTECTED]
Using "/home/wejn/x/docs/html:/home/wejn/x/docs1/html" as value of
open_basedir is senseless, as it's similar to
"/home/wejn/x/docs/html:/home/wejn/x/docs/html", because open_basedir's
values are resolved too.
Obviously PHP cannot resolve "/home/wejn/x/docs1/html/y" as it even
doesn't exist, so it compares non-existing "/home/wejn/x/docs1/html/y"
to "/home/wejn/x/docs/html/" and reports that they aren't the same.
Please, stop reopening this report and begin to respect people that
wasting their own free time to help you.
[2004-11-28 16:58:48] lists+php at box dot cz
No, you're simply WRONG:
"->All symbolic
links are resolved, so it's not possible to avoid this restriction
with
a symlink.<-"
because my open_basedir is set to:
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"
therefore the file lies in basedir either way, when I call:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
It's a bug and I would expect someone with email "@php.net" to at least
READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over
and over again, because you simply assume from beginning that I'm wrong
(and the only action you do is actually telling me bullshit about
RTFM).
I did RTFM, but your implementation simply doesn't correspond with the
things written in TFM.
[offensive]
Anyway, I don't care about PHP anymore - I have better things to do
than pushing you to at least read what you're responding to ... btw,
responding to bugreports after 2 months is really, really wonderful.
Better than never, though.
[/offensive]
[2004-11-28 15:16:38] [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
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. ->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"
http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir
You have to copy file to "/home/wejn/x/docs1/html/" instead of it's
symlink if want open_basedir to work properly.
[2004-10-14 12:10:46] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
[2004-10-14
#27663 [Com]: compile fails with cURL 7.11.1
ID: 27663 Comment by: thomas-lists at myphorum dot com Reported By: toni dot viemero at iki dot fi Status: Assigned Bug Type: Compile Failure Operating System: Debian Woody PHP Version: 4.3.5RC4 Assigned To: iliaa New Comment: Oh please, don't fix it only after release, don't leave us using php-4.3.5 with a broken curl-extension :(. btw. having the same prob. Previous Comments: [2004-03-23 15:57:22] [EMAIL PROTECTED] Will be fixed after 4.3.5 release. [2004-03-23 15:39:35] toni dot viemero at iki dot fi Tested compiling with RC3 and cURL 7.11.1 with same effect. Breaks with cURL upgrade from 7.11.0 to 7.11.1. [2004-03-23 15:31:43] toni dot viemero at iki dot fi Description: Building 4.3.5RC4 with cURL 7.11.1 doesn't compile Builds fine with 4.3.5RC3 and cURL 7.11.0 /bin/sh /root/src/php-4.3.5RC4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/root/src/php-4.3.5RC4/ext/curl/ -DPHP_ATOM_INC -I/root/src/php-4.3.5RC4/include -I/root/src/php-4.3.5RC4/main -I/root/src/php-4.3.5RC4 -I/root/src/php-4.3.5RC4/Zend -I/usr/local/curl/include -I/usr/include/libxml2 -I/usr/local/freetype/include -I/usr/local/freetype/include/freetype2 -I/usr/local/gd/include -I/root/src/imap-2002e/c-client -I/usr/local/mysql/include -I/root/src/php-4.3.5RC4/ext/xml/expat -I/root/src/php-4.3.5RC4/TSRM -g -O2 -prefer-pic -c /root/src/php-4.3.5RC4/ext/curl/curl.c -o ext/curl/curl.lo /root/src/php-4.3.5RC4/ext/curl/curl.c: In function `curl_free_post': /root/src/php-4.3.5RC4/ext/curl/curl.c:568: warning: passing arg 1 of `curl_formfree' from incompatible pointer type /root/src/php-4.3.5RC4/ext/curl/curl.c: In function `alloc_curl_handle': /root/src/php-4.3.5RC4/ext/curl/curl.c:608: sizeof applied to an incomplete type /root/src/php-4.3.5RC4/ext/curl/curl.c: In function `zif_curl_setopt': /root/src/php-4.3.5RC4/ext/curl/curl.c:845: duplicate case value /root/src/php-4.3.5RC4/ext/curl/curl.c:700: this is the first entry for that value /root/src/php-4.3.5RC4/ext/curl/curl.c:890: warning: passing arg 1 of `curl_formadd' from incompatible pointer type /root/src/php-4.3.5RC4/ext/curl/curl.c:890: warning: passing arg 2 of `curl_formadd' from incompatible pointer type /root/src/php-4.3.5RC4/ext/curl/curl.c:898: warning: passing arg 1 of `curl_formadd' from incompatible pointer type /root/src/php-4.3.5RC4/ext/curl/curl.c:898: warning: passing arg 2 of `curl_formadd' from incompatible pointer type make: *** [ext/curl/curl.lo] Error 1 $ /usr/local/curl/bin/curl -V curl 7.11.1 (i686-pc-linux-gnu) libcurl/7.11.1 OpenSSL/0.9.7d zlib/1.1.4 Protocols: ftp gopher telnet dict ldap http file https ftps Features: SSL libz NTLM Largefile -- Edit this bug report at http://bugs.php.net/?id=27663&edit=1
#28012 [NEW]: spprintf() output inconsistent for %p (fix included)
From: php-lists at nomeaning dot net Operating system: linux RH 9 PHP version: 5CVS-2004-04-15 (dev) PHP Bug Type: Output Control Bug description: spprintf() output inconsistent for %p (fix included) Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit bug report at http://bugs.php.net/?id=28012&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28012&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28012&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28012&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28012&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28012&r=support Expected behavior: http://bugs.php.net/fix.php?id=28012&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28012&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28012&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28012&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28012&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28012&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28012&r=float
#28012 [Opn]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Open Bug Type: Output Control Operating System: linux RH 9 PHP Version: 5CVS-2004-04-15 (dev) New Comment: H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! Previous Comments: [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28012 [Opn]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Open Bug Type: Output Control Operating System: linux RH 9 PHP Version: 5CVS-2004-04-15 (dev) New Comment: Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. Previous Comments: [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#28012 [Csd]: spprintf() output inconsistent for %p (fix included)
ID: 28012 User updated by: php-lists at nomeaning dot net Reported By: php-lists at nomeaning dot net Status: Closed Bug Type: Output Control Operating System: * PHP Version: 5.0.0RC2RC1 New Comment: Happy to help. Re: The security risk. I guess I failed to convey that my "patch" to var.c was merely to make reproducing the bug earlier for you. By no means was I suggesting putting it in CVS! (though the idea of printing pointers in var_dump() for --enable-debug mode is a good one) Previous Comments: [2004-04-15 19:09:55] [EMAIL PROTECTED] Thanks for noticing. But printing the pointers through var.c is a nice thing for debugging but is a security risk for non debug mode. [2004-04-15 19:08:11] [EMAIL PROTECTED] 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. [2004-04-15 17:23:23] php-lists at nomeaning dot net Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to [EMAIL PROTECTED] Sorry for the confusion. [2004-04-15 17:15:56] php-lists at nomeaning dot net H... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access. Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here. http://www.nomeaning.net/temp/spprintf.tgz The contents of the .tgz are: 1) The proposed fix, in spprintf.c.patch 2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch. It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down. Hope this helps! ---- [2004-04-15 17:07:21] php-lists at nomeaning dot net Description: In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any). If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended. If the previously-converted argument was zero or a non-integer, the prefix will be missing. Reproduce code: --- I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump. To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array. Expected result: "0x" should prefix every pointer value, to indicate a hexadecimal address. -- Edit this bug report at http://bugs.php.net/?id=28012&edit=1
#30188 [NEW]: open_basedir check is badly performed under some circumstances
From: lists+php at box dot cz
Operating system: Linux (Gentoo, latest)
PHP version: 5.0.1
PHP Bug Type: Filesystem function related
Bug description: open_basedir check is badly performed under some circumstances
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in various filesystem functions)?
Btw, this problem exists also in 4.3.8, which makes me think that it's
there for a LONG time ... unnoticed.
W.
Reproduce code:
---
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');
Expected result:
no error.
Actual result:
--
Warning: copy() [function.copy]: open_basedir restriction in effect.
File(/home/wejn/x/docs/html/y) is not within the allowed path(s):
(/home/wejn/x/docs/html:/home/wejn/x/docs1/html) in
/home/wejn/x/docs1/html/index.html on line 2
Warning: copy(/home/wejn/x/docs/html/y) [function.copy]: failed to open
stream: Operation not permitted in /home/wejn/x/docs1/html/index.html on
line 2
--
Edit bug report at http://bugs.php.net/?id=30188&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30188&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30188&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30188&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30188&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30188&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30188&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30188&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30188&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30188&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30188&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30188&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30188&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30188&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30188&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30188&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30188&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30188&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30188&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30188&r=mysqlcfg
#30188 [Opn]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
Status: Open
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?
> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it into a directory for its own.
OK ... but the rest still applies. The code is obviously broken. And
sorry, folks @ php.net ... but if I would ever use PHP in production, I
would expect bugs to be solved in timely fashion, not after 6 months of
waiting as "open" (or even not solved at all).
It imho says all the "right" things about PHP - it's still toy, it has
(almost) no support, nobody really cares about users' aches, ...
It's simply another hack-it-yourself-or-shut-up thingie ... but I'm
probably crying on wrong shoulder here, anyway. :)
Previous Comments:
[2004-10-14 11:51:28] evp at heise dot de
> Maybe it would be better to perform open_basedir check just
> on dirs
> instead of files (in various filesystem functions)?
No, because it's sometimes vital to have files in open_basedir to allow
acces to one specific file without the need to put it into a directory
for its own.
----
[2004-09-21 23:50:28] lists+php at box dot cz
Description:
My setup:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to:
"/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to
"/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.
IMO, there is problem with symlink resolving code somewhere under
php_check_specific_open_basedir().
It seems to me that more precise location of the bug is somewhere in
virtual_file_ex() regarding the realpath() call.
Maybe it would be better to perform open_basedir check just on dirs
instead of files (in various filesystem functions)?
Btw, this problem exists also in 4.3.8, which makes me think that it's
there for a LONG time ... unnoticed.
W.
Reproduce code:
---
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');
Expected result:
no error.
Actual result:
--
Warning: copy() [function.copy]: open_basedir restriction in effect.
File(/home/wejn/x/docs/html/y) is not within the allowed path(s):
(/home/wejn/x/docs/html:/home/wejn/x/docs1/html) in
/home/wejn/x/docs1/html/index.html on line 2
Warning: copy(/home/wejn/x/docs/html/y) [function.copy]: failed to open
stream: Operation not permitted in /home/wejn/x/docs1/html/index.html on
line 2
--
Edit this bug report at http://bugs.php.net/?id=30188&edit=1
Bug #60922 [Com]: tests fail for mhash() and mhash_keygen_s2k() functions and MHASH_TIGER
Edit report at https://bugs.php.net/bug.php?id=60922&edit=1
ID: 60922
Comment by: jamie-lists at boxlightmedia dot com
Reported by:silvan at etoy dot com
Summary:tests fail for mhash() and mhash_keygen_s2k()
functions and MHASH_TIGER
Status: Assigned
Type: Bug
Package:mhash related
Operating System: Mac OS X
PHP Version:5.4SVN-2012-01-29 (SVN)
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Also failing for me on 5.4RC6 (PHP 5.4.0-rc6-pl0-gentoo (cli) (built: Jan 30
2012
11:59:37)
Result
---
MHASH_GOST
ok
MHASH_TIGER: string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
MHASH_TIGER: string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
If I swap back to PHP 5.3.9-pl0-gentoo (cli) (built: Jan 30 2012 13:21:46), it
returns the correct hash.
Previous Comments:
[2012-01-30 12:35:30] m...@php.net
Oh my, mhash compat mode of ext/hash eh?
I totally missed that while fixing bug #60221.
[2012-01-29 10:53:16] silvan at etoy dot com
Description:
make test failed test summary:
mhash() test [ext/hash/tests/mhash_001.phpt]
mhash_keygen_s2k() test [ext/hash/tests/mhash_003.phpt
mhash_003.out:
MHASH_TIGER: string(200)
"67eac97b9dca0a47b1f6262f330264e4ce1c233760fe3255f642512fd3127929baccf1e758236b2768a4c2c0c06e118b19e40e2f04a5f745820fb8a99bdbc00698702a4d3120171856c4c94bda79ba1b4f60d509d7f8954da818a29797368dd47c1122aa"
MHASH_TIGER: string(200)
"470aca9d7bc9ea67e46402332f26f6b15532fe6037231cce297912d32f5142f6276b2358e7f1ccba8b116ec0c0c2a46845f7a5042f0ee41906c0db9ba9b80f82181720314d2a70981bba79da4bc9c4564d95f8d709d5604fd48d369797a218a862196f48"
Test script:
---
mhash_003.php
foreach ($supported_hash_al as $hash=>$wanted) {
$passwd = str_repeat($hash, 10);
$salt = str_repeat($hash, 2);
$result = mhash_keygen_s2k(constant($hash), $passwd, $salt, 100);
if (!strcmp(bin2hex($result), $wanted)) {
echo "$hash\nok\n";
} else {
echo "$hash: ";
var_dump($wanted);
echo "$hash: ";
var_dump(bin2hex($result));
}
echo "\n";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60922&edit=1
#42143 [Com]: The constant NAN is reported as 0 on Windows build
ID: 42143
Comment by: php-lists at stanvassilev dot com
Reported By: zoe at uk dot ibm dot com
Status: Assigned
Bug Type: Math related
Operating System: win32 only
PHP Version: 5CVS, 6CVS (2008-11-01)
Assigned To: pajoye
New Comment:
There are two separate bugs here. I've actually reported the other
part individually but it was marked bogus (see #46868).
Bug 1) PHP relies on the compiler's semantics alone for NaN
comparisons, and that seems to differ from compiler to compiler, and
even in the same compiler depending on the particular setup. This
means on some builds NaN == NaN and on some NaN != NaN. On the current
builds at On Windows in particular, VC9, however will compute NaN ==
NaN as false, while with VC6 it'll be false or true depending on the
particular setup.
Note that I'm not comparing the constants, but actual NaN (this test
is carried out on a VC6 TS build of PHP 5.2.9):
var_dump(NAN); // float(0)
var_dump(sqrt(-1)); // float(NAN)
var_dump(sqrt(-1) == sqrt(-1)); // true (should be false)
This means that we should codify how exactly does NaN compare to other
values and itself, and add a special case code above compiler logic in
the equality operators. As a high level language, there's no need for
PHP to depend on compiler's minutae, when we at the same time do such
expensive operations such as checking two strings for numeric content
before comparing.
In the definition of NaN itself is said that NaN should not match
anything or even itself, and this is the consistent implementation in
all popular script languages today:
http://en.wikipedia.org/wiki/NaN
Given the current status quo, most deployments are under *nix, where
the behavior is silent NaN (no errors, propagates on math operations
having one or more NaN), and NaN doesn't match itself.
So to stabilize this behavior for "niche" platforms, we just need to
compiler-proof the code a bit with a special case logic (pseudo code):
function equals(op1, op2) {
if (is_nan(op1) || is_nan(op2)) {
return false;
} else {
return op1 == op2; // else use current equality logic
}
}
I've not done work on the PHP core, so I hope someone can provide the
patch here.
Bug 2) On Windows platforms it seems in most builds NAN is just
reported as 0 (this bug). From my tests, on all current Win32 builds
of 5.2.x and 5.3.x, NAN is reported as 0, including *VC9* builds.
I have no idea why this is happening, but this might be a clue
(implicit conversion and the value is lost):
http://www.velocityreviews.com/forums/t283018-compiletime-constant-
quiet-nan-double-.html
The strange thing here is that math operations apparently *do* produce
actual NaN (see test above on Bug 1), even if the constant NAN is 0.
Previous Comments:
[2008-07-18 16:24:55] j...@php.net
Pierre, assigning to you since Edin is MIA.
[2007-08-03 05:24:53] paj...@php.net
Little notice about VC6, using it with the very last SDK works. I'm not
sure which SDK is used on our win32 build box. It may be a platform sdk
bug more than a VC bug. Edin, can you try to upgrade the SDK (if we can
upgrade it:)?
[2007-08-02 22:27:25] s...@php.net
Saw a bug under msvc2005 that can be related to this - get_nan()
function produced FP exception. Weird thing is that it happens only if
engine is started, shut down and then started again inside the same
process. Maybe has something to do with some kind of floating point.
Using PHP_DOUBLE_QUIET_NAN_HIGH instead seems to fix the problem.
[2007-08-02 09:47:42] paj...@php.net
I tried using vc 2k3 and 2k5 and NAN is correctly defined. VC6 seems to
have a different way to define/get/use NAN. Maybe we can rely on
fmod(1,0) instead (always return NaN on windows).
[2007-07-31 11:42:49] j...@php.net
Edin, can you check if there's some problem with the win32 build in
this?
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/42143
--
Edit this bug report at http://bugs.php.net/?id=42143&edit=1
#42143 [Com]: The constant NAN is reported as 0 on Windows build
ID: 42143
Comment by: php-lists at stanvassilev dot com
Reported By: zoe at uk dot ibm dot com
Status: Assigned
Bug Type: Math related
Operating System: win32 only
PHP Version: 5CVS, 6CVS (2008-11-01)
Assigned To: pajoye
New Comment:
Actually I just tested on Win32 PHP 5.2.9 VC6 TS (official php.net
build) and this is a lot worse than I thought:
var_dump(sqrt(-1) == 123); // float(true)
var_dump(sqrt(-1) == "hi there"); // float(true)
var_dump(sqrt(-1) == null); // float(true)
var_dump(sqrt(-1) == false); // float(true)
var_dump(sqrt(-1) == 0.1); // float(true)
Instead of being equal to nothing, it's equal to almost everything...
Previous Comments:
[2009-05-24 11:57:51] php-lists at stanvassilev dot com
There are two separate bugs here. I've actually reported the other
part individually but it was marked bogus (see #46868).
Bug 1) PHP relies on the compiler's semantics alone for NaN
comparisons, and that seems to differ from compiler to compiler, and
even in the same compiler depending on the particular setup. This
means on some builds NaN == NaN and on some NaN != NaN. On the current
builds at On Windows in particular, VC9, however will compute NaN ==
NaN as false, while with VC6 it'll be false or true depending on the
particular setup.
Note that I'm not comparing the constants, but actual NaN (this test
is carried out on a VC6 TS build of PHP 5.2.9):
var_dump(NAN); // float(0)
var_dump(sqrt(-1)); // float(NAN)
var_dump(sqrt(-1) == sqrt(-1)); // true (should be false)
This means that we should codify how exactly does NaN compare to other
values and itself, and add a special case code above compiler logic in
the equality operators. As a high level language, there's no need for
PHP to depend on compiler's minutae, when we at the same time do such
expensive operations such as checking two strings for numeric content
before comparing.
In the definition of NaN itself is said that NaN should not match
anything or even itself, and this is the consistent implementation in
all popular script languages today:
http://en.wikipedia.org/wiki/NaN
Given the current status quo, most deployments are under *nix, where
the behavior is silent NaN (no errors, propagates on math operations
having one or more NaN), and NaN doesn't match itself.
So to stabilize this behavior for "niche" platforms, we just need to
compiler-proof the code a bit with a special case logic (pseudo code):
function equals(op1, op2) {
if (is_nan(op1) || is_nan(op2)) {
return false;
} else {
return op1 == op2; // else use current equality logic
}
}
I've not done work on the PHP core, so I hope someone can provide the
patch here.
Bug 2) On Windows platforms it seems in most builds NAN is just
reported as 0 (this bug). From my tests, on all current Win32 builds
of 5.2.x and 5.3.x, NAN is reported as 0, including *VC9* builds.
I have no idea why this is happening, but this might be a clue
(implicit conversion and the value is lost):
http://www.velocityreviews.com/forums/t283018-compiletime-constant-
quiet-nan-double-.html
The strange thing here is that math operations apparently *do* produce
actual NaN (see test above on Bug 1), even if the constant NAN is 0.
[2008-07-18 16:24:55] j...@php.net
Pierre, assigning to you since Edin is MIA.
[2007-08-03 05:24:53] paj...@php.net
Little notice about VC6, using it with the very last SDK works. I'm not
sure which SDK is used on our win32 build box. It may be a platform sdk
bug more than a VC bug. Edin, can you try to upgrade the SDK (if we can
upgrade it:)?
[2007-08-02 22:27:25] s...@php.net
Saw a bug under msvc2005 that can be related to this - get_nan()
function produced FP exception. Weird thing is that it happens only if
engine is started, shut down and then started again inside the same
process. Maybe has something to do with some kind of floating point.
Using PHP_DOUBLE_QUIET_NAN_HIGH instead seems to fix the problem.
[2007-08-02 09:47:42] paj...@php.net
I tried using vc 2k3 and 2k5 and NAN is correctly defined. VC6 seems to
have a different way to define/get/use NAN. Maybe we can rely on
fmod(1,0) instead (always return NaN on windows).
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/42143
--
Edit this bug report at http://bugs.php.net/?id=42143&edit=1
#42143 [Com]: The constant NAN is reported as 0 on Windows build
ID: 42143
Comment by: php-lists at stanvassilev dot com
Reported By: zoe at uk dot ibm dot com
Status: Assigned
Bug Type: Math related
Operating System: win32 only
PHP Version: 5CVS, 6CVS (2008-11-01)
Assigned To: pajoye
New Comment:
Naturally I mean bool(true) in the previous comment, not float(true)...
;)
Previous Comments:
[2009-05-24 12:45:32] php-lists at stanvassilev dot com
Actually I just tested on Win32 PHP 5.2.9 VC6 TS (official php.net
build) and this is a lot worse than I thought:
var_dump(sqrt(-1) == 123); // float(true)
var_dump(sqrt(-1) == "hi there"); // float(true)
var_dump(sqrt(-1) == null); // float(true)
var_dump(sqrt(-1) == false); // float(true)
var_dump(sqrt(-1) == 0.1); // float(true)
Instead of being equal to nothing, it's equal to almost everything...
[2009-05-24 11:57:51] php-lists at stanvassilev dot com
There are two separate bugs here. I've actually reported the other
part individually but it was marked bogus (see #46868).
Bug 1) PHP relies on the compiler's semantics alone for NaN
comparisons, and that seems to differ from compiler to compiler, and
even in the same compiler depending on the particular setup. This
means on some builds NaN == NaN and on some NaN != NaN. On the current
builds at On Windows in particular, VC9, however will compute NaN ==
NaN as false, while with VC6 it'll be false or true depending on the
particular setup.
Note that I'm not comparing the constants, but actual NaN (this test
is carried out on a VC6 TS build of PHP 5.2.9):
var_dump(NAN); // float(0)
var_dump(sqrt(-1)); // float(NAN)
var_dump(sqrt(-1) == sqrt(-1)); // true (should be false)
This means that we should codify how exactly does NaN compare to other
values and itself, and add a special case code above compiler logic in
the equality operators. As a high level language, there's no need for
PHP to depend on compiler's minutae, when we at the same time do such
expensive operations such as checking two strings for numeric content
before comparing.
In the definition of NaN itself is said that NaN should not match
anything or even itself, and this is the consistent implementation in
all popular script languages today:
http://en.wikipedia.org/wiki/NaN
Given the current status quo, most deployments are under *nix, where
the behavior is silent NaN (no errors, propagates on math operations
having one or more NaN), and NaN doesn't match itself.
So to stabilize this behavior for "niche" platforms, we just need to
compiler-proof the code a bit with a special case logic (pseudo code):
function equals(op1, op2) {
if (is_nan(op1) || is_nan(op2)) {
return false;
} else {
return op1 == op2; // else use current equality logic
}
}
I've not done work on the PHP core, so I hope someone can provide the
patch here.
Bug 2) On Windows platforms it seems in most builds NAN is just
reported as 0 (this bug). From my tests, on all current Win32 builds
of 5.2.x and 5.3.x, NAN is reported as 0, including *VC9* builds.
I have no idea why this is happening, but this might be a clue
(implicit conversion and the value is lost):
http://www.velocityreviews.com/forums/t283018-compiletime-constant-
quiet-nan-double-.html
The strange thing here is that math operations apparently *do* produce
actual NaN (see test above on Bug 1), even if the constant NAN is 0.
[2008-07-18 16:24:55] j...@php.net
Pierre, assigning to you since Edin is MIA.
[2007-08-03 05:24:53] paj...@php.net
Little notice about VC6, using it with the very last SDK works. I'm not
sure which SDK is used on our win32 build box. It may be a platform sdk
bug more than a VC bug. Edin, can you try to upgrade the SDK (if we can
upgrade it:)?
[2007-08-02 22:27:25] s...@php.net
Saw a bug under msvc2005 that can be related to this - get_nan()
function produced FP exception. Weird thing is that it happens only if
engine is started, shut down and then started again inside the same
process. Maybe has something to do with some kind of floating point.
Using PHP_DOUBLE_QUIET_NAN_HIGH instead seems to fix the problem.
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/42143
--
Edit this bug report at http://bugs.php.net/?id=42143&edit=1
[PHP-BUG] Req #52052 [NEW]: add syslog support to FPM
From: Operating system: Linux/*NIX PHP version: 5.3SVN-2010-06-11 (SVN) Package: FPM related Bug Type: Feature/Change Request Bug description:add syslog support to FPM Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit bug report at http://bugs.php.net/bug.php?id=52052&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52052&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52052&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52052&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52052&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52052&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52052&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52052&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52052&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52052&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52052&r=support Expected behavior: http://bugs.php.net/fix.php?id=52052&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52052&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52052&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52052&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52052&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52052&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52052&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52052&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52052&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52052&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52052&r=mysqlcfg
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 User updated by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: Great job! :-) I'll try it out and report feedback to you. Previous Comments: [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 ---- [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 User updated by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level -> slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar Previous Comments: [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 ---- [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. 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/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary:add syslog support to FPM Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux/*NIX PHP Version:5.3SVN-2010-06-11 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Hi Jerome, are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5 the latest patch doesn't work anymore. I'd be willing to port it to the latest release, if you're interested. I'd still like to see this integrated into trunk and 5.3.X. Regards, Edgar Previous Comments: [2010-07-22 23:37:45] f...@php.net some answers to your questions: 1- this is a bug. All comparaison should use strcasecmp so that users can type facilities and log level with the case they want. 2- you're right. php_syslog() should be used instead of syslog() 4- after testing and validating, yes of course. I need to take time reviewing all this. Thx again ! [2010-07-07 13:17:07] f...@php.net Thanks for the reporting. I'll check that and answer you as soon as possible. ---- [2010-07-07 12:27:54] ef-lists at email dot de Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level -> slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 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/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 User updated by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary:add syslog support to FPM Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux/*NIX PHP Version:5.3SVN-2010-06-11 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Hi, added a new patch, which can be applied to a vanilla PHP 5.3.5. compiles and runs with: --enable-debug without relevant warnings --enable-maintainer-zts without other flags with having HAVE_SYSLOG_H in main/php_config.h undefined changes: * modified patch to work with FPM in 5.3.5 * added new parameters to config dump (todo: translate syslog prio and facility to nice human-readable values) * made comparing syslog facilities case-insensitive * replaced syslog() calls with php_syslog() Regards, Edgar Previous Comments: [2011-01-12 16:15:58] ef-lists at email dot de Hi Jerome, are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5 the latest patch doesn't work anymore. I'd be willing to port it to the latest release, if you're interested. I'd still like to see this integrated into trunk and 5.3.X. Regards, Edgar [2010-07-22 23:37:45] f...@php.net some answers to your questions: 1- this is a bug. All comparaison should use strcasecmp so that users can type facilities and log level with the case they want. 2- you're right. php_syslog() should be used instead of syslog() 4- after testing and validating, yes of course. I need to take time reviewing all this. Thx again ! [2010-07-07 13:17:07] f...@php.net Thanks for the reporting. I'll check that and answer you as soon as possible. ---- [2010-07-07 12:27:54] ef-lists at email dot de Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level -> slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. 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/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 User updated by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary:add syslog support to FPM Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux/*NIX PHP Version:5.3SVN-2010-06-11 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Oh you're right. We're actually experiencing this issue here. At least the master process should always log to the configured ident/facility - that's configuration and process manager warnings/errors. By far the most important log output from FPM, IMHO. I don't think this is a critical issue for FPM, as log output is never discarded and other sapis (milter, thttpd, mod_php with Apache ErrorLog set to syslog) do it the same way - although it would be nice to see this resolved. I still wonder how to properly do this... open a separate socket and mimic syslog behaviour? How to address this on Windows? If you have updates, I'd be really curious. If I can help, let me know. :-) Previous Comments: [2011-01-29 15:46:44] f...@php.net thx for the up to date patch. But there is still a remaining problem: php_syslog(), openlog() and closelog() can be called from FPM code, core code, user script, module, sapi, ... If two calls to openlog() are made from two different places. Then this is not sure than php_syslog() will log the right ident and facility. This a global reflection to make around PHP and not only in FPM. I'm working on it. ---- [2011-01-28 15:53:44] ef-lists at email dot de Hi, added a new patch, which can be applied to a vanilla PHP 5.3.5. compiles and runs with: --enable-debug without relevant warnings --enable-maintainer-zts without other flags with having HAVE_SYSLOG_H in main/php_config.h undefined changes: * modified patch to work with FPM in 5.3.5 * added new parameters to config dump (todo: translate syslog prio and facility to nice human-readable values) * made comparing syslog facilities case-insensitive * replaced syslog() calls with php_syslog() Regards, Edgar ---- [2011-01-12 16:15:58] ef-lists at email dot de Hi Jerome, are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5 the latest patch doesn't work anymore. I'd be willing to port it to the latest release, if you're interested. I'd still like to see this integrated into trunk and 5.3.X. Regards, Edgar [2010-07-22 23:37:45] f...@php.net some answers to your questions: 1- this is a bug. All comparaison should use strcasecmp so that users can type facilities and log level with the case they want. 2- you're right. php_syslog() should be used instead of syslog() 4- after testing and validating, yes of course. I need to take time reviewing all this. Thx again ! [2010-07-07 13:17:07] f...@php.net Thanks for the reporting. I'll check that and answer you as soon as possible. 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/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #54152 [Com]: Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi
Edit report at https://bugs.php.net/bug.php?id=54152&edit=1 ID: 54152 Comment by: apache-lists at riggs dot me Reported by:mark at catseye dot org Summary:Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi Status: Closed Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3SVN-2011-03-03 (snap) Assigned To:jimjag Block user comment: N Private report: N New Comment: This fix does not take into account using mod_proxy_balancer. When I use this same setup using mod_proxy_fcgi as a BalancerMember, I get a SCRIPT_FILENAME of proxy:balancer:// Should this be reopened to handle that, or should we create a new bug? Previous Comments: [2011-03-29 13:39:13] mark at catseye dot org v3 of the patch was applied to trunk in r309054 http://svn.php.net/viewvc?view=revision&revision=309054 [2011-03-09 19:53:24] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309054 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 19:27:31] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309053 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 18:56:17] mark at catseye dot org Tested v3 of the patch against development snapshot php5.3-201103091530. Verified that the script gets executed, SCRIPT_FILENAME is set correctly, PATH_INFO is set correctly, and the php-fpm status page works. Compared output of phpinfo() between version 2 and version 3 of the patch for requests with extra-path components and query strings; did not find any discrepancies. Reviewed the patch itself and it looks good. [2011-03-07 19:50:54] jim...@php.net please try v3 of the patch... This limits the later on version of the changes to just be in effect when we know we're handling the proxy:fcgi:// stuff 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 https://bugs.php.net/bug.php?id=54152 -- Edit this bug report at https://bugs.php.net/bug.php?id=54152&edit=1
#28796 [Com]: Apache eat all Memory (parent::$this->__construct())
ID: 28796
Comment by: derrickbtan dot lists at gmail dot com
Reported By: felix at trilithium dot de
Status: No Feedback
Bug Type: Apache related
Operating System: Linux version 2.4.21-199-default
PHP Version: 5.0.0RC3
New Comment:
Shouldn't this invalid syntax be caught @ compile/run time? I ran into
the same mistake when my IDE added $this-> to the function name during
autocompletion. . . Since essentially the parent:: is ignored,
shouldn't this syntax be considered invalid??
Previous Comments:
[2004-09-16 01:00:08] 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".
[2004-09-08 05:41:49] [EMAIL PROTECTED]
parent::$this->__construct makes no sense, are you sure you didn't mean
parent parent::__construct()
[2004-06-18 17:41:46] benjcarson at digitaljunkies dot ca
$this->__construct() is a recursive call to secondClass' constructor.
Since the constructor never returns, the recursion never bottoms out;
it is effectively an infinite loop. Each call consumes space on the
stack, so eventually PHP chews up all available memory and dies.
You would see the same behaviour if secondClass' constructor was:
function __construct() {
$this->__construct();
}
What you really want, as alex dot pagnoni at solarix dot it has pointed
out is:
function __construct() {
parent::__construct();
}
[2004-06-17 13:38:32] alex dot pagnoni at solarix dot it
is parent::$this->__construct() the correct syntax? Wasn't
it supposed to be parent::__construct()?
[2004-06-15 17:03:13] felix at trilithium dot de
Description:
Apache eat all memory when your try the example code
Reproduce code:
---
class firstClass{
function __construct(){
echo __CLASS__."::".__FUNCTION__."";
}
function test(){
echo __CLASS__."::".__FUNCTION__."";
return $this;
}
}
class secondClass extends firstClass{
function __construct(){
echo __CLASS__."::".__FUNCTION__."";
parent::$this->__construct(); //<-here Apache eat all memory
//parent::$this->test(); // this works
}
}
$e= new secondClass;
--
Edit this bug report at http://bugs.php.net/?id=28796&edit=1
[PHP-BUG] Bug #53797 [NEW]: PCRE_DOTALL modifier overrides non-greedy operator
From: Operating system: Windows 7 PHP version: 5.3.5 Package: PCRE related Bug Type: Bug Bug description:PCRE_DOTALL modifier overrides non-greedy operator Description: If the PCRE_DOTALL 's' modifier is specified in the regex, instances of the non-greedy (lazy) operator '?' are ignored. Test script: --- $input = <
