Bug #62956 [Asn]: incompatible signatures for private methods should not cause E_STRICT
Edit report at https://bugs.php.net/bug.php?id=62956edit=1
ID: 62956
Updated by: lsm...@php.net
Reported by:lsm...@php.net
Summary:incompatible signatures for private methods should
not cause E_STRICT
Status: Assigned
Type: Bug
Package:Unknown/Other Function
PHP Version:5.4.6
Assigned To:lstrojny
Block user comment: N
Private report: N
New Comment:
appears to be a duplicate of #61761
Previous Comments:
[2012-08-28 11:02:32] lsm...@php.net
BTW: A temporary fix is to simply rename the method in the extending class.
[2012-08-28 10:58:59] lsm...@php.net
Description:
Defining a private method in an extending class that matches the name of a
private
method in a parent class with a different signature currently triggers an
E_STRICT. As the extending class shouldn't see the parent private methods,
there
is no reason to trigger an E_STRICT in this case.
Test script:
---
?php
class A
{
private function foo($bar)
{
}
}
class B extends A
{
private function foo()
{
}
}
Expected result:
no E_STRICT error
Actual result:
--
PHP Strict standards: Declaration of B::foo() should be compatible with
A::foo($bar) in /Users/lsmith/htdocs/foo.php on line 15
Strict standards: Declaration of B::foo() should be compatible with
A::foo($bar)
in /Users/lsmith/htdocs/foo.php on line 15
--
Edit this bug report at https://bugs.php.net/bug.php?id=62956edit=1
Bug #43200 [Opn]: Interface implementation / inheritence not possible in abstract classes
Edit report at https://bugs.php.net/bug.php?id=43200edit=1
ID: 43200
Updated by: lsm...@php.net
Reported by:smith at pooteeweet dot org
Summary:Interface implementation / inheritence not possible
in abstract classes
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3CVS-2007-11-05 (CVS)
Block user comment: N
Private report: N
New Comment:
I should also clarify that the issue also exist when simply dealing with
interfaces only aka when an interface extends another interface. I am aware
that
we do not support polymorphism, but again when dealing with legacy interfaces
there will be overlaps with signatures that are identical.
Previous Comments:
[2011-10-02 21:16:11] ahar...@php.net
Revert the various field changes that crept in. I'll let one of the engine
developers figure out if this should be left open or re-bogused.
[2011-10-01 07:55:33] lsm...@php.net
This is not bogus and it should be fixed. In many cases I in the end managed to
work around this, but its not always possible, like when dealing with legacy
interfaces that one cannot change etc, but that are being superseded by newer
ones (f.e. https://github.com/symfony/symfony/pull/2244).
[2010-12-16 00:38:40] kucho86 at gmail dot com
Are you planning to cover this bug??
It's pretty simple to fix and since interfaces define behaviours and classes
implements them, this should be possible.
It goes against Object Oriented Programming concepts.
[2007-11-05 16:34:21] cel...@php.net
?php
interface A {
function foo();
}
abstract class B implements A {
}
class C extends B {
public function foo() {
echo 'works';
}
}
$o = new C();
$o-foo();
?
If you don't want to implement a method from an interface, don't
redeclare it, and the code will work as intended.
[2007-11-05 15:50:30] smith at pooteeweet dot org
Description:
PHP 5.3.0-dev (cli) (built: Nov 5 2007 16:42:56) from todays CVS HEAD.
The implementation of interfaces in concrete abstract classes and their
inheritence is not possible:
Reproduce code:
---
?php
interface A {
function foo();
}
abstract class B implements A {
abstract public function foo();
}
class C extends B {
public function foo() {
echo 'works';
}
}
$o = new C();
$o-foo();
?
Expected result:
Echoing works
Actual result:
--
Fatal error: Can't inherit abstract function A::foo() (previously declared
abstract in B) in ...
--
Edit this bug report at https://bugs.php.net/bug.php?id=43200edit=1
Bug #43200 [Bgs-Opn]: sm...@pooteeweet.org
Edit report at https://bugs.php.net/bug.php?id=43200edit=1
ID: 43200
Updated by: lsm...@php.net
Reported by:smith at pooteeweet dot org
-Summary:Interface implementation / inheritence not possible
in abstract classes
+Summary:sm...@pooteeweet.org
-Status: Bogus
+Status: Open
Type: Bug
Package:Scripting Engine problem
-Operating System: Linux
+Operating System: sm...@pooteeweet.org
-PHP Version:5.3CVS-2007-11-05 (CVS)
+PHP Version:sm...@pooteeweet.org
-Assigned To:
+Assigned To:sm...@pooteeweet.org
Block user comment: N
Private report: N
New Comment:
This is not bogus and it should be fixed. In many cases I in the end managed to
work around this, but its not always possible, like when dealing with legacy
interfaces that one cannot change etc, but that are being superseded by newer
ones (f.e. https://github.com/symfony/symfony/pull/2244).
Previous Comments:
[2010-12-16 00:38:40] kucho86 at gmail dot com
Are you planning to cover this bug??
It's pretty simple to fix and since interfaces define behaviours and classes
implements them, this should be possible.
It goes against Object Oriented Programming concepts.
[2007-11-05 16:34:21] cel...@php.net
?php
interface A {
function foo();
}
abstract class B implements A {
}
class C extends B {
public function foo() {
echo 'works';
}
}
$o = new C();
$o-foo();
?
If you don't want to implement a method from an interface, don't
redeclare it, and the code will work as intended.
[2007-11-05 15:50:30] smith at pooteeweet dot org
Description:
PHP 5.3.0-dev (cli) (built: Nov 5 2007 16:42:56) from todays CVS HEAD.
The implementation of interfaces in concrete abstract classes and their
inheritence is not possible:
Reproduce code:
---
?php
interface A {
function foo();
}
abstract class B implements A {
abstract public function foo();
}
class C extends B {
public function foo() {
echo 'works';
}
}
$o = new C();
$o-foo();
?
Expected result:
Echoing works
Actual result:
--
Fatal error: Can't inherit abstract function A::foo() (previously declared
abstract in B) in ...
--
Edit this bug report at https://bugs.php.net/bug.php?id=43200edit=1
Bug #52257 [Opn]: module php5-librdf causes libxslt's security module to fail
Edit report at http://bugs.php.net/bug.php?id=52257edit=1
ID: 52257
Updated by: lsm...@php.net
Reported by:matth at mlalonde dot net
Summary:module php5-librdf causes libxslt's security module
to fail
Status: Open
Type: Bug
Package:XSLT related
Operating System: Ubuntu LTS
PHP Version:5.3.2
Block user comment: N
New Comment:
to add some more context about the issue, i talked to the author of php
rdf ext
on the #reland freenode IRC channel:
[15:23] dajobe lsmith: it's not the php module, it's raptor which
redland uses
[15:23] dajobe it sets the libxslt security policy
[15:24] dajobe http://librdf.org/raptor/api-1.4/raptor-section-
general.html#raptor-set-libxslt-security-preferences
[15:25] dajobe it's hard to do - how is raptor/redland suppose to know
when a
calling application is also wanting to adjust parameters of a shared
library
[15:26] dajobe it's the calling app's responsibility - php in this
case
Previous Comments:
[2010-07-30 10:55:44] penny at liip dot ch
I had exactly the same problem with the following versions:
libxslt1.1 1.1.24-2
php55.2.6.dfsg.1-1+lenny8
php5-librdf 1.0.7.1-1+b1
Purging php5-librdf fixed the problem.
[2010-07-06 00:46:03] matth at mlalonde dot net
Description:
I have been able to replicate under three environment running Ubuntu LTS
php5 (cli, cgi or mod_php), libxslt 1.1.26 and the php5 module and
librdf0 and the php5 module.
With the above setup, any xsl:import href=local/file.xsl / call will
fail with the error
XSLTProcessor::importStylesheet(): Local file read for
/path/to/local/file.xsl refused
Using XSLCache will result in a segfault and no errors.
Removing php5's librdf module fixes the issue.
Test script:
---
# a.php
?php
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL|E_STRICT|E_NOTICE);
//phpinfo();
$doc = new DOMDocument();
$xsl = new XSLTProcessor();
$xsl_filename = __DIR__ . '/collection.xsl';
$xml_filename = __DIR__ . '/collection.xml';
$doc-load($xsl_filename);
$xsl-importStyleSheet($doc);
$doc-load($xml_filename);
echo $xsl-transformToXML($doc);
# collection.xml
collection
cd
titleFight for your mind/title
artistBen Harper/artist
year1995/year
/cd
cd
titleElectric Ladyland/title
artistJimi Hendrix/artist
year1997/year
/cd
/collection
# collection.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:import href=file:///var/www/pgadmin/temp/collection2.xsl /
xsl:param name=owner select='Nicolas Eliaszewicz'/
xsl:output method=html encoding=iso-8859-1 indent=no/
xsl:template match=collection
Hey! Welcome to xsl:value-of select=$owner/'s sweet CD
collection!
xsl:apply-templates/
/xsl:template
xsl:template match=cd
h1xsl:value-of select=title//h1
h2by xsl:value-of select=artist/ - xsl:value-of
select=year//h2
hr /
/xsl:template
/xsl:stylesheet
# collection2.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:param name=owner select='Nicolas Eliaszewicz'/
xsl:output method=html encoding=iso-8859-1 indent=no/
xsl:template match=collection
Hey! Welcome to xsl:value-of select=$owner/'s sweet CD
collection!
xsl:apply-templates/
/xsl:template
xsl:template match=cd
h1xsl:value-of select=title//h1
h2by00 xsl:value-of select=artist/ - xsl:value-of
select=year//h2
hr /
/xsl:template
/xsl:stylesheet
Expected result:
A parsed XSLT document with the imported stylesheets. And no errors ;)
Actual result:
--
Warning: XSLTProcessor::importStylesheet(): error in /var/www/temp/a.php
on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2. XSLTProcessor-importStylesheet()
/var/www/temp/a.php:14
Warning: XSLTProcessor::importStylesheet(): Local file read for
file:///var/www/pgadmin/temp/collection2.xsl refused in
/var/www/temp/a.php on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2. XSLTProcessor-importStylesheet()
/var/www/temp/a.php:14
--
Edit this bug report at http://bugs.php.net/bug.php?id=52257edit=1
Bug #52257 [Opn]: module php5-librdf causes libxslt's security module to fail
Edit report at http://bugs.php.net/bug.php?id=52257edit=1
ID: 52257
Updated by: lsm...@php.net
Reported by:matth at mlalonde dot net
Summary:module php5-librdf causes libxslt's security module
to fail
Status: Open
Type: Bug
Package:XSLT related
Operating System: Ubuntu LTS
PHP Version:5.3.2
Block user comment: N
New Comment:
some additional infos from Dave Beckett:
but anyway, more info at
http://bugs.librdf.org/mantis/view.php?id=379
I found I could duplicate the error and as I suspected if I made raptor
skip
over xsltSetSecurityPrefs() and xsltSetDefaultSecurityPrefs() calls,
the
program works as expected.
I can probably patch raptor to fix this, then patch the librdf-php to
use that
fix, but that's quite indirect.
Seems all libxslt users in the same memory space will have this issue.
Previous Comments:
[2010-08-06 15:35:38] lsm...@php.net
to add some more context about the issue, i talked to the author of php
rdf ext
on the #reland freenode IRC channel:
[15:23] dajobe lsmith: it's not the php module, it's raptor which
redland uses
[15:23] dajobe it sets the libxslt security policy
[15:24] dajobe http://librdf.org/raptor/api-1.4/raptor-section-
general.html#raptor-set-libxslt-security-preferences
[15:25] dajobe it's hard to do - how is raptor/redland suppose to know
when a
calling application is also wanting to adjust parameters of a shared
library
[15:26] dajobe it's the calling app's responsibility - php in this
case
[2010-07-30 10:55:44] penny at liip dot ch
I had exactly the same problem with the following versions:
libxslt1.1 1.1.24-2
php55.2.6.dfsg.1-1+lenny8
php5-librdf 1.0.7.1-1+b1
Purging php5-librdf fixed the problem.
[2010-07-06 00:46:03] matth at mlalonde dot net
Description:
I have been able to replicate under three environment running Ubuntu LTS
php5 (cli, cgi or mod_php), libxslt 1.1.26 and the php5 module and
librdf0 and the php5 module.
With the above setup, any xsl:import href=local/file.xsl / call will
fail with the error
XSLTProcessor::importStylesheet(): Local file read for
/path/to/local/file.xsl refused
Using XSLCache will result in a segfault and no errors.
Removing php5's librdf module fixes the issue.
Test script:
---
# a.php
?php
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL|E_STRICT|E_NOTICE);
//phpinfo();
$doc = new DOMDocument();
$xsl = new XSLTProcessor();
$xsl_filename = __DIR__ . '/collection.xsl';
$xml_filename = __DIR__ . '/collection.xml';
$doc-load($xsl_filename);
$xsl-importStyleSheet($doc);
$doc-load($xml_filename);
echo $xsl-transformToXML($doc);
# collection.xml
collection
cd
titleFight for your mind/title
artistBen Harper/artist
year1995/year
/cd
cd
titleElectric Ladyland/title
artistJimi Hendrix/artist
year1997/year
/cd
/collection
# collection.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:import href=file:///var/www/pgadmin/temp/collection2.xsl /
xsl:param name=owner select='Nicolas Eliaszewicz'/
xsl:output method=html encoding=iso-8859-1 indent=no/
xsl:template match=collection
Hey! Welcome to xsl:value-of select=$owner/'s sweet CD
collection!
xsl:apply-templates/
/xsl:template
xsl:template match=cd
h1xsl:value-of select=title//h1
h2by xsl:value-of select=artist/ - xsl:value-of
select=year//h2
hr /
/xsl:template
/xsl:stylesheet
# collection2.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:param name=owner select='Nicolas Eliaszewicz'/
xsl:output method=html encoding=iso-8859-1 indent=no/
xsl:template match=collection
Hey! Welcome to xsl:value-of select=$owner/'s sweet CD
collection!
xsl:apply-templates/
/xsl:template
xsl:template match=cd
h1xsl:value-of select=title//h1
h2by00 xsl:value-of select=artist/ - xsl:value-of
select=year//h2
hr /
/xsl:template
/xsl:stylesheet
Expected result:
A parsed XSLT document with the imported stylesheets. And no errors ;)
Actual result:
--
Warning: XSLTProcessor::importStylesheet(): error in /var/www/temp/a.php
on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2. XSLTProcessor-importStylesheet()
/var/www/temp/a.php:14
Warning: XSLTProcessor::importStylesheet(): Local file read for
file:///var/www/pgadmin/temp/collection2.xsl refused in
/var/www/temp/a.php on line 14
Call Stack:
0.0002 627304 1. {main}() /var/www/temp/a.php:0
0.0006 631128 2
#44383 [NoF-Opn]: PHP DateTime not converted to xsd:datetime
ID: 44383 Updated by: lsm...@php.net Reported By: kevin dot craft at gmail dot com -Status: No Feedback +Status: Open Bug Type: SOAP related Operating System: Windows XP PHP Version: 5.2.6 New Comment: Reopening since we now have a patch. Previous Comments: [2009-06-29 08:28:26] david dot zuelke at bitextender dot com We've created a patch to implement this. Description (with patch and tests for download): http://article.gmane.org/gmane.comp.php.devel/57369 Patch (in case gmane doesn't work): http://pastie.org/527755 Tests (in case gmane doesn't work): http://pastie.org/527762 [2009-05-06 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-05-04 10:56:14] bme at hst dot aau dot dk I tried the snapshot on windows xp, apache 2.2, with the php code supplied in this thread and this is what I see: Request: soapenv:Envelope xmlns:xsi=hxxp://www.w3.org/2001/XMLSchema-instance xmlns:xsd=hxxp://www.w3.org/2001/XMLSchema xmlns:soapenv=hxxp://schemas.xmlsoap.org/soap/envelope/ xmlns:urn=urn:xmethods-delayed-quotes soapenv:Header/ soapenv:Body urn:getCurrentDate soapenv:encodingStyle=hxxp://schemas.xmlsoap.org/soap/encoding// /soapenv:Body /soapenv:Envelope Response: SOAP-ENV:Envelope SOAP-ENV:encodingStyle=hxxp://schemas.xmlsoap.org/soap/encoding/ xmlns:SOAP-ENV=hxxp://schemas.xmlsoap.org/soap/envelope/ xmlns:ns1=urn:xmethods-delayed-quotes xmlns:SOAP-ENC=hxxp://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi=hxxp://www.w3.org/2001/XMLSchema-instance xmlns:xsd=hxxp://www.w3.org/2001/XMLSchema SOAP-ENV:Body ns1:getCurrentDateResponse currentDate xsi:type=SOAP-ENC:Struct/ /ns1:getCurrentDateResponse /SOAP-ENV:Body /SOAP-ENV:Envelope Assuming the supplied wsdl and php server/client is correct, DateTime is still not being served correctly. I am not even seeing xsd:datetime in the response. Allt http have been changed to hxxp to be able to post the comment. [2009-04-28 18:37:21] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-12-10 13:44:17] martijn dot zijlstra at gmail dot com still not fixed in 5.2.6-0.dotdeb.1 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/44383 -- Edit this bug report at http://bugs.php.net/?id=44383edit=1
#48642 [Asn-Bgs]: Missing command in make file for Generating phar.php
ID: 48642 Updated by: lsm...@php.net Reported By: gareth dot randall at virgin dot net -Status: Assigned +Status: Bogus Bug Type: Compile Failure Operating System: AIX 6.1 PHP Version: 5.3.0RC4 Assigned To: cellog New Comment: closed until we get details. i guess since the issue will likely be something else, open a new bug. Previous Comments: [2009-06-23 18:46:08] gareth dot randall at virgin dot net Just realised that I was trying to build it with AIX make, rather than GNU make. I've tried again with GNU make, which fails elsewhere, so I'll report the full details of that tomorrow. [2009-06-23 11:24:36] paj...@php.net Can you take a look please? [2009-06-22 11:37:59] gareth dot randall at virgin dot net Description: The Generating phar.php section of make fails with the error: /bin/sh[14]: -d: not found. Thoughts: Generating phar.php only occurs once in Makefile. The command run begins with: @$(PHP_PHARCMD_EXECUTABLE) $(PHP_PHARCMD_SETTINGS) [other bits removed] Since PHP_PHARCMD_SETTINGS starts with -d, it looks as if the PHP_PHARCMD_EXECUTABLE is coming out empty. Please advise me of any checks or fixes you would like me to try. Reproduce code: --- cd php-5.3.0RC4 ./configure make Expected result: make process completes without error. Actual result: -- (Previous make output omitted...) Generating phar.php /bin/sh[14]: -d: not found. make: 1254-004 The error code from the last command is 127. Stop. -- Edit this bug report at http://bugs.php.net/?id=48642edit=1
#48247 [Csd-Opn]: PHP crashes on errors during startup
ID: 48247 Updated by: lsm...@php.net Reported By: dmi...@php.net -Status: Closed +Status: Open Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2009-05-12) Assigned To: derick Previous Comments: [2009-06-16 17:38:28] s...@php.net See also bug #48534 [2009-05-31 21:32:08] s...@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. Should be fixed now in 5.2+ [2009-05-13 18:21:36] j...@php.net I fixed the first part (dependancy issues + loading order), Derick can now fix the second part and add infinite recursion protection and make init tzcache be done in GINIT _and_ RINIT (if ! init - init.. :) [2009-05-13 07:09:31] dmi...@php.net Unfortunately this patch doesn't fix the bug. [2009-05-13 00:46:26] j...@php.net Dmitry, I committed a fix in HEAD. Please check it out. If you agree, I'll MFH to other branches. 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/48247 -- Edit this bug report at http://bugs.php.net/?id=48247edit=1
#47021 [Opn-Asn]: SoapClient stumbles over WSDL delivered with Transfer-Encoding: chunked
ID: 47021
Updated by: lsm...@php.net
Reported By: daniel dot gorski at develnet dot org
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.3CVS-2009-01-06 (CVS)
Assigned To: dmitry
Previous Comments:
[2009-01-26 10:54:53] giovanni at giacobbi dot net
Please see related discussion:
http://marc.info/?t=12329199332r=1w=2
See also bug report #43069 which actually caused this bug.
[2009-01-22 15:35:02] ml at x-net dot be
I can confirm this bug. I tried avoiding the chunking in Apache by
using mod_deflate, but the PHP SOAP client probably doesn't send an
Accept-Encoding header with gzip in it.
[2009-01-06 16:28:52] daniel dot gorski at develnet dot org
Description:
The \SoapClient (and probably the \SoapServer) stumble over WSDL files
that are delivered via HTTP in chunks, carrying the HTTP response header
Transfer-Encoding: chunked.
Reproduce code:
---
$sc = \SoapClient('http://any.wsdl/that/is/delivered/in/chunks');
Expected result:
No error, intantiation and initialization of the \SoapClient object.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from [URL]: Start tag expected, '' not found in
[FILE]
--
Edit this bug report at http://bugs.php.net/?id=47021edit=1
#46767 [Opn-Asn]: FastCGI Error is returned when connecting to a MySQL server with PHP 5.3 Alpha3
ID: 46767 Updated by: lsm...@php.net Reported By: peaceable_whale at hotmail dot com -Status: Open +Status: Assigned Bug Type: MySQLi related Operating System: win32 only PHP Version: 5.3.0alpha3 Assigned To: mysql Previous Comments: [2009-02-02 14:06:14] peaceable_whale at hotmail dot com No. The error occurs once the script connects to a database. Test case: ?php $mysqli=new mysqli(HOST,USERNAME,PASSWORD); $connection_closed=$mysqli-close(); echo $connection_closed?Database connection has been closed successfully:An error occurred when closing database connection; ? [2009-02-02 13:43:30] johan...@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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Does a simple mysql_connect() or mysqli_connect() work? Do simple queries work? Do other applications than phpMyAdmin work? [2009-02-02 13:35:42] peaceable_whale at hotmail dot com Thanks for changing it to Assigned :) [2009-02-02 13:33:57] paj...@php.net oh my bad, right. So not related (it must be the 1st report in weeks not related to 5.1 =) assigned to mysql [2009-02-02 13:32:22] peaceable_whale at hotmail dot com Well, mysqlnd is in use as it is turned on by default in the Windows builds: mysqli MysqlI Support enabled Client API library version mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.21 $ Active Persistent Links 0 Inactive Persistent Links 0 Active Links0 mysqlnd mysqlnd enabled Version mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.21 $ Command buffer size 2048 Read buffer size32768 Collecting statistics Yes Collecting memory statisticsNo 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/46767 -- Edit this bug report at http://bugs.php.net/?id=46767edit=1
#47286 [Opn-Asn]: oci8 and pdo_oci aren't in 5.3.0B1 builds
ID: 47286 Updated by: lsm...@php.net Reported By: christopher dot jones at oracle dot com -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 5.3.0beta1 Assigned To: pierre Previous Comments: [2009-02-03 01:31:32] christopher dot jones at oracle dot com Description: The 5.3.0beta1 bundles from http://windows.php.net/qa/ are missing php_oci8.dll, php_oci8_11g.dll and pdo_oci.dll. These extensions are present in the PHP 5.3 snaps on http://windows.php.net/snapshots/ -- Edit this bug report at http://bugs.php.net/?id=47286edit=1
#46026 [Csd-Asn]: bz2.decompress/zlib.inflate filter tries to decompress after end of stream
ID: 46026
Updated by: lsm...@php.net
Reported By: Keisial at gmail dot com
-Status: Closed
+Status: Assigned
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
Assigned To: cellog
Previous Comments:
[2008-10-11 21:54:13] Keisial at gmail dot com
Wow, thank you very much. :-)
Sorry about the tabs. My editor messed them (I know, I know, real
programmers use butterflies...).
However, consider doing this:
if (SUCCESS == zend_hash_find(HASH_OF(filterparams), concatenated,
sizeof(concatenated), (void **) tmpzval) ) {
-SEPARATE_ZVAL(tmpzval);
-convert_to_boolean_ex(tmpzval);
data-expect_concatenated = Z_LVAL_PP(tmpzval);
-zval_ptr_dtor(tmpzval);
tmpzval = NULL;
}
There were memory corruption problems with the previous patch, and
zval_ptr_dtor seemed to be the source (thanks to rrichards and pajoye
for their help on this on irc). Also, the other zval_ptr_dtor below
(present there since first version by Sara) would be a good possible
candidate for another possible point of mem corruption.
[2008-10-11 19:15:22] cel...@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.
fixed in PHP 5.2, 5.3, 6.0. Concatenation was only added in PHP 5.3
and 6.0, as new features cannot be added to PHP 5.2
[2008-10-11 19:08:35] cel...@php.net
changing summary to reflect addition of zlib problem
[2008-10-11 18:25:14] cel...@php.net
In the future, please follow 2 important elements of the coding
standards:
1) use tabs instead of spaces
2) always use {} around if/else blocks
I had to waste 15 minutes just getting the patch formatted correctly
before I could even begin testing it. I don't like wasting time.
[2008-10-11 17:12:10] cel...@php.net
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
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/46026
--
Edit this bug report at http://bugs.php.net/?id=46026edit=1
#44151 [Opn-Asn]: Errors not cleaned properly
ID: 44151
Updated by: lsm...@php.net
Reported By: uwendel at mysql dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: davidc
Previous Comments:
[2008-12-17 18:05:38] dav...@php.net
Could you please test with the latest CVS or snapshot please? I have
made a few changes related to that lately and I'm wondering if that
could have fixed it.
Thanks,
[2008-02-18 16:51:11] uwendel at mysql dot com
Description:
According to the manual, PDO::errorInfo() returns the error information
about the last operation performed by this database handle,
http://www.php.net/manual/en/function.PDO-errorInfo.php
What is PDO supposed to return if you perform two operations of which
the first fails and the second works fine, like this:
[1] THIS IS NO VALID SQL, I HOPE
[2] CREATE TABLE test(id int NOT NULL PRIMARY KEY, val VARCHAR(10), grp
VARCHAR(10))
Should errorInfo() return the error information from [1] or will the
error information be cleared prior to running [2]. In the latter case,
the user is given an additional easy way to check if an operation has
failed or not.
And the latter case (clear info before running [2]) is what I as the
desired behaviour.
Next question: which elements of the errorInfo() element shall be
reset? Currently it seems to me as if the SQLSTATE code is reset to
'0' but some drivers (e.g. PDO/MySQL, PDO/SQLlite, maybe more) do
not reset their driver specific fields. Haven't checked if that's an
issue caused by code from ext/pdo or from ext/pdo_mydriver.
Reproduce code:
---
--TEST--
PDO Common: PDO-errorInfo(), clear line after error
--SKIPIF--
?php # vim:ft=php
if (!extension_loaded('pdo')) die('skip');
$dir = getenv('REDIR_TEST_DIR');
if (false == $dir) die('skip no driver');
require_once $dir . 'pdo_test.inc';
PDOTest::skip();
?
--FILE--
?php
if (getenv('REDIR_TEST_DIR') === false)
putenv('REDIR_TEST_DIR='.dirname(__FILE__) . '/../../pdo/tests/');
require_once getenv('REDIR_TEST_DIR') . 'pdo_test.inc';
$db = PDOTest::factory('PDO', false);
$db = PDOTest::factory('PDO', false);
@$db-exec('THIS IS NO VALID SQL, I HOPE');
var_dump($db-errorInfo());
var_dump($db-errorCode());
$db-exec('CREATE TABLE test(id int NOT NULL PRIMARY KEY, val
VARCHAR(10), grp VARCHAR(10))');
var_dump($db-errorInfo());
var_dump($db-errorCode());
print done!;
?
--EXPECTF--
array(3) {
[0]=
string(5) %s
[1]=
int(%d)
[2]=
string(%d) %s
}
string(5) %s
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
string(5) 0
done!
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=44151edit=1
#46408 [Bgs-Opn]: Locale number format settings can cause pg_query_params to break with numerics
ID: 46408 Updated by: [EMAIL PROTECTED] Reported By: alec at smecher dot bc dot ca -Status: Bogus +Status: Open Bug Type: PostgreSQL related Operating System: Debian testing PHP Version: 5.2.7RC2 New Comment: RhodiumToad lsmith: in a parameterized query it's always wrong to use locale-specific delimiters RhodiumToad is also known as Andrew Gierth and is a highly respected expert on #postgresql on freenode. As such I will reopen the bug .. Previous Comments: [2008-11-10 17:59:56] alec at smecher dot bc dot ca [EMAIL PROTECTED], please have a look at PostgreSQL's number parsing function (set_var_from_str in src/backend/utils/adt/numeric.c, e.g. at http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/numeric.c?rev=1.114). It's hard-coded to expect a period as the decimal separator. Long story short, if you supply a floating point value to pg_query_params and you're using a PHP locale that formats floats with a comma, pg_query_params will generate SQL that will cause a parse error. IMO, the use of a locale-specific float-to-string conversion in PHP's implementation of pg_query_params is the bug. [2008-10-31 18:28:57] alec at smecher dot bc dot ca FYI, there's a discussion of the same bug, which also appeared (in a separate implementation) in the implementation of the Pear::DB package: http://pear.php.net/bugs/bug.php?id=3021 [2008-10-28 22:54:37] alec at smecher dot bc dot ca In case it wasn't clear, the bug IMO is that pg_query_params is using a means to convert doubles to strings that is potentially incompatible with the database. [2008-10-28 21:35:51] alec at smecher dot bc dot ca Sorry if I've missed something in the documentation, but this definitely looks like a bug to me. I expect pg_query_params, when given a double, to communicate it to the database properly regardless of PHP's number format settings. Could I have a little more feedback? [2008-10-28 21:30:50] [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 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/46408 -- Edit this bug report at http://bugs.php.net/?id=46408edit=1
#46326 [Opn-Asn]: error_reporting ignored in php-cli.ini
ID: 46326 Updated by: [EMAIL PROTECTED] Reported By: RQuadling at GMail dot com -Status: Open +Status: Assigned Bug Type: PHP options/info functions Operating System: Windows XP SP3 PHP Version: 5.3CVS-2008-10-17 (snap) -Assigned To: +Assigned To: pajoye Previous Comments: [2008-10-23 13:24:39] RQuadling at GMail dot com Wouldn't surprise me. [2008-10-22 11:25:29] [EMAIL PROTECTED] So it's most likely Windows only issue. (can't reproduce here..) [2008-10-21 19:09:45] RQuadling at GMail dot com real? raspberry But no. I'm all windows here. [2008-10-21 09:29:02] [EMAIL PROTECTED] Can you reproduce this with some real OS, line Linux? [2008-10-17 13:25:38] RQuadling at GMail dot com Oh and supplying the INI file via the command line on the 5.3 alpha makes no difference either ... C:\c:\PHP5\php.exe -c C:\php\PHP5\INI\php-cli.ini z:\phpdetails.php php_sapi_name() = cli phpversion()= 5.3.0alpha3-dev php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 22519 INI error_reporting = error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR 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/46326 -- Edit this bug report at http://bugs.php.net/?id=46326edit=1
#46241 [Ctl-Asn]: Error handler stacking broken
ID: 46241
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Gentoo
PHP Version: 5.3.0alpha2
-Assigned To:
+Assigned To: colder
Previous Comments:
[2008-10-22 22:32:01] [EMAIL PROTECTED]
Upgrading to critical, as it is a crash and clear breakage of
functionality.
[2008-10-21 21:04:33] clemens dot kalb at netlogix dot de
Here is one thing that has been more clear in the other, duplicate and
now closed - bug entry (#46338). The first code sample with object
methods does not only miss out on the second error handler, it also
segfaults *on shutdown* of the PHP process:
---SNIP-
Starting program: /usr/bin/php5 segfault2.php
[Thread debugging using libthread_db enabled]
[New Thread -1215695168 (LWP 5622)]
Caught on first level: 'Foo'
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1215695168 (LWP 5622)]
zend_hash_destroy (ht=0xb786bf08) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_hash.c:524
524 p = p-pListNext;
(gdb) bt
#0 zend_hash_destroy (ht=0xb786bf08) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_hash.c:524
#1 0x0836dc41 in _zval_dtor_func (zvalue=0xb786bf70) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_variables.c:43
#2 0x0836d3b3 in zend_ptr_stack_apply (stack=0x880d470, func=0x836dbf0
_zval_dtor_func) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_ptr_stack.c:90
#3 0x0836d3fd in zend_ptr_stack_clean (stack=0x880d470, func=0x836dbf0
_zval_dtor_func, free_elements=1 '\001')
at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_ptr_stack.c:97
#4 0x08360f68 in shutdown_executor () at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend_execute_API.c:272
#5 0x0836e28b in zend_deactivate () at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/Zend/zend.c:899
#6 0x08316df6 in php_request_shutdown (dummy=0x0) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/main/main.c:1522
#7 0x08408203 in main (argc=2, argv=0xbffa0b14) at
/usr/src/dailybuild/builds/20081021/php5-5.3.0-200810211830/sapi/cli/php_cli.c:1311
---SNAP-
The problem persists with PHP 5.3.0alpha3-dev (cli) (built: Oct 21 2008
22:10:26).
[2008-10-06 13:03:21] [EMAIL PROTECTED]
Description:
Stacking 2 error handlers is broken. With object methods only the first
error handler is invoked, with functions I even get a PHP crash.
Reproduce code:
---
-- Object methods ---
?php
class ErrorHandling
{
public function errorHandler1( $errno, $errstr )
{
echo Caught on first level: '$errstr'\n;
return true;
}
public function errorHandler2( $errno, $errstr )
{
echo Caught on second level: '$errstr'\n;
return true;
}
}
$err = new ErrorHandling();
set_error_handler( array( $err, 'errorHandler1' ) );
set_error_handler( array( $err, 'errorHandler2' ) );
trigger_error( 'Foo', E_USER_WARNING );
?
-- Functions ---
?php
function errorHandler1( $errno, $errstr )
{
echo Caught on first level: '$errstr'\n;
return true;
}
function errorHandler2( $errno, $errstr )
{
echo Caught on second level: '$errstr'\n;
return true;
}
set_error_handler( 'errorHandler1' );
set_error_handler( 'errorHandler2' );
trigger_error( 'Foo', E_USER_WARNING );
?
Expected result:
-- Object methods ---
Caught on second level: 'Foo'
-- Functions ---
Caught on second level: 'Foo'
Actual result:
--
-- Object methods ---
Caught on first level: 'Foo'
-- Functions ---
Caught on first level: 'Foo'
zend_mm_heap corrupted
--
Edit this bug report at http://bugs.php.net/?id=46241edit=1
#44449 [Opn-Asn]: DateTime from timestamp failing if DST
ID: 9 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: MacOS 10.5.2 PHP Version: 5.3CVS-2008-03-16 (snap) -Assigned To: +Assigned To: derick Previous Comments: [2008-03-16 17:31:15] [EMAIL PROTECTED] Description: Test ext/date/tests/bug40743.phpt fails ONLY if the current date is set to DST; see below. If this isn't actually a bug (as in #41912), then the test should take this into account. sarcasmic:~/svn/php.net/php5$ date Sat 16 Feb 2008 13:25:26 EST sarcasmic:~/svn/php.net/php5$ TEST_PHP_EXECUTABLE=~/src/php5.3-200803081530/sap i/cli/php sapi/cli/php ./run-tests.php ext/date/tests/bug40743.phpt = PHP : /Users/sean/src/php5.3-200803081530/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.0-dev ZEND_VERSION: 2.3.0 PHP_OS : Darwin - Darwin sarcasmic 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 INI actual : /Users/sean/svn/php.net/php5 More .INIs : CWD : /Users/sean/svn/php.net/php5 Extra dirs : VALGRIND: Not used = Running selected tests. PASS Bug #40743 (DateTime ignores the TimeZone object passed to the constructor) [ext/date/tests/bug40743.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) - Time taken :0 seconds = sarcasmic:~/svn/php.net/php5$ date Sun 16 Mar 2008 13:25:56 EDT sarcasmic:~/svn/php.net/php5$ TEST_PHP_EXECUTABLE=~/src/php5.3-200803081530/sap i/cli/php sapi/cli/php ./run-tests.php ext/date/tests/bug40743.phpt = PHP : /Users/sean/src/php5.3-200803081530/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.0-dev ZEND_VERSION: 2.3.0 PHP_OS : Darwin - Darwin sarcasmic 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 INI actual : /Users/sean/svn/php.net/php5 More .INIs : CWD : /Users/sean/svn/php.net/php5 Extra dirs : VALGRIND: Not used = Running selected tests. FAIL Bug #40743 (DateTime ignores the TimeZone object passed to the constructor) [ext/date/tests/bug40743.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - Bug #40743 (DateTime ignores the TimeZone object passed to the constructor) [ext/date/tests/bug40743.phpt] = Diff: 005+ Wed, 16 Jan 08 18:04:59 +0100 +01:00 GMT+0100 +0100 1200506699 005- Wed, 16 Jan 08 18:04:59 + +00:00 GMT+ + 1200506699 -- Edit this bug report at http://bugs.php.net/?id=9edit=1
#46044 [Opn-Asn]: Mysqli - wrong error message
ID: 46044
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.3CVS-2008-09-10 (CVS)
-Assigned To:
+Assigned To: mysql
Previous Comments:
[2008-09-10 17:46:24] [EMAIL PROTECTED]
See also:
new mysqli_stmt(new mysqli('localhost', 'root'));
[2008-09-10 17:41:08] [EMAIL PROTECTED]
Description:
See below.
Reproduce code:
---
new mysqli_result(1); // Error! OK
Warning: mysqli_result::mysqli_result() expects parameter 1 to be
mysqli, integer given in /home/felipe/public_html/bug.php on line 4
new mysqli('localhost', 'root'); // No error, OK!
new mysqli_result(new mysqli('localhost', 'root')); // hm!?!?!?
Warning: mysqli::mysqli() expects parameter 1 to be string, object
given in /home/felipe/public_html/bug.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=46044edit=1
#46105 [Opn-Asn]: mysql_fetch_object calls constructor on object after setting up properties
ID: 46105
Updated by: [EMAIL PROTECTED]
Reported By: ninzya at inbox dot lv
-Status: Open
+Status: Assigned
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0alpha2
-Assigned To:
+Assigned To: mysql
Previous Comments:
[2008-09-17 12:35:52] ninzya at inbox dot lv
Description:
when using custom object return through mysql_fetch_object, function
allocates specified in second parameter object, sets up all properties
and then calls constructor. I think this is wrong. Newly instantiated
object's constructor must be called before any other operation on the
object is performed.
Reproduce code:
---
/**
* Object class
*
*/
class Object {
/**
* Array of properties
*
* @var array
*/
protected $_props =array();
/**
* Construct object
*
* @param array $props
*/
public function __construct( $props =array()) {
var_dump( 'constr');
$this-_props =$props;
}
/**
* Magic method override
*
* @param string $key
*/
public function __isset( $key) {
var_dump( 'isset');
return array_key_exists( $key, $this-_props);
}
/**
* Magic method override
*
* @param string $key
* @return mixed/null
*/
public function __get( $key) {
var_dump( 'get');
if( !array_key_exists( $key, $this-_props))
return null;// entry does not exist
// return obtained value
return $this-_props[ $key];
}
/**
* Magic method override
*
* @param string $key
* @param mixed $value
*/
public function __set( $key, $value) {
var_dump( 'set');
$this-_props[ $key] =$value;
}
/**
* Magic method override
*
* @param string $key
*/
public function __unset( $key) {
var_dump( 'unset');
unset( $this-_props[ $key]);
}
/**
* Get associated array
*
* @return array
*/
public function __invoke() {
var_dump( 'invoke');
return $this-_props;
}
/**
* Get object name
*
* @return string
*/
public function __toString() {
return __CLASS__;
}
}
..
mysql_fetch_object( $result, 'Object');
Expected result:
string(6) constr
string(3) set
string(3) set
string(3) set
string(3) set
Actual result:
--
string(3) set
string(3) set
string(3) set
string(3) set
string(6) constr
--
Edit this bug report at http://bugs.php.net/?id=46105edit=1
#45808 [Opn-Asn]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 Updated by: [EMAIL PROTECTED] Reported By: six at aegis-corp dot org -Status: Open +Status: Assigned Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 -Assigned To: +Assigned To: pajoye Previous Comments: [2008-09-25 17:59:37] singularity_control at rcpt dot at This makes a serious security issue. It is a very effective DoS on all single process PHP servers with SSL and a slightly less bad DoS on multi-process PHP servers. [2008-09-25 16:07:31] nasam at mailvault dot com Bug is in ext/openssl/xp_ssl.c Function handle_ssl_error: (line 107) case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: /* re-negotiation, or perhaps the SSL layer needs more * packets: retry in next iteration */ errno = EAGAIN; retry = is_init ? 1 : sslsock-s.is_blocked; //BUG break; it sets retry to 1 in php_openssl_enable_crypto no matter if socket is blocking or not. [2008-09-25 10:06:09] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-23 01:00:00] 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. 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/45808 -- Edit this bug report at http://bugs.php.net/?id=45808edit=1
#42632 [Opn-Bgs]: PDO fetch doesn't preserve case
ID: 42632
Updated by: [EMAIL PROTECTED]
Reported By: mattsch at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Gentoo Linux
PHP Version: 5.2.4
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behavior. The SQL standard mandates that identifiers
are not case sensitive and that all unquoted identifiers be returned in
upper case. However this is a question of the underlying client API. In
the case of PostgreSQL the developers deliberately decided to return
identifiers lower case by default. You can force a specific case (though
not mixed case or case preserving) via a connection/statement level
attribute. Check the documentation.
Previous Comments:
[2007-09-11 21:31:00] mattsch at gmail dot com
Description:
PDO fetch doesn't preserve the case of the column. I don't know if
this is a feature or if it is a bug, but if it is a feature since
the beginning of PDO, could I also suggest that another flag be added
for PDO fetch to tell it to preserve the case?
Reproduce code:
---
?php
try {
$pdo = new PDO(pgsql:host={$host};dbname={$database}, $user,
$password);
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo-query(SET search_path to {$schema});
$accountState = $pdo-prepare('
SELECT id AS accountId
FROM account
WHERE id = ?
');
$accountState-bindParam(1, $id, PDO::PARAM_INT);
$accountState-execute();
$getAccount = $accountState-fetch(PDO::FETCH_OBJ);
$accountState-closeCursor();
var_dump($getAccount);
} catch (Exception $e){
print An error occurred: {$e-getMessage()};
}
?
Expected result:
object(stdClass)#8 (1) {
[accountId]=
int(339)
}
Actual result:
--
object(stdClass)#8 (1) {
[accountid]=
int(339)
}
--
Edit this bug report at http://bugs.php.net/?id=42632edit=1
#39449 [Csd-Opn]: Overloaded array properties do not work correctly
ID: 39449 Updated by: [EMAIL PROTECTED] Reported By: pstradomski at gmail dot com -Status: Closed +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.2.0 Assigned To: dmitry New Comment: I am still seeing this issue on PHP 5.2.5. Here is a link to a PEAR class affected: http://pear.php.net/bugs/bug.php?id=10702 The method in question can be found here: http://pear.php.net/package/XML_Feed_Parser/docs/latest/__filesource/f source_XML_Feed_Parser__XML_Feed_Parser-1.0.2ParserType.php.html#a189 Changing $this-idMappings[$id] = $this-entries[$offset]; to $mappings = $this-idMappings; $mappings[$id] = $this-entries[$offset]; $this-idMappings = $mappings; fixes the notice .. Previous Comments: [2007-01-10 16:01:10] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_2. [2007-01-06 10:19:01] slavikus at gmail dot com I do agree with the brjann points and also vote for this behavior to be fixed; there's no way for me to knowing if any particular property is overloaded or not, neither it is right to treat them differently from any other properties. [2006-12-22 12:20:30] tim dot pickup at gmail dot com Just adding a comment to say this feature is also going to cause me a lot of pain changing code. Any reason it is expected behaviour or do we just get a 4 word reply basically saying you ? [2006-12-15 19:32:06] davidm at marketo dot com I agree strongly with brjann's analysis. Once the language allows overloaded properties on an object, it's completely confusing to say that overloaded array properties are immutable while all other property types are mutable, and also that non-overloaded array properties can be iterated with foreach but overloaded array properties cannot be iterated. I've got a significant amount of code that will have to be rewritten because of this change. The symfony framework encourages a design pattern that uses overloaded properties on the action objects and any instances where the overloaded property is an array are now broken. Other symfony users have run into the problem as well (http://www.symfony-project.com/forum/index.php/m/15684/#msg_15684). David Morandi [2006-12-06 22:18:09] mail at peter-thomassen dot de I do agree with Denis in the sense that one should disable the notice for read access (using foreach, p.ex.), until a global solution including write access is found (or not). This doesn't harm anyone and would save me some lines of error_reporting() changes. Thanks! 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/39449 -- Edit this bug report at http://bugs.php.net/?id=39449edit=1
#40740 [Asn]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at filofox dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux Debian Sarge 3.1
PHP Version: 5.2.1
Assigned To: wez
New Comment:
Well there is no way to hint to MySQL if something is a string or not
using emulate_prepare. What I think could make sense is for MySQL to
look at the type though.
So that:
$foo = '1'; // quoted as a string
$foo = 1; // interpreted as an integer and therefore not quoted
This should be fine for security as well, since integers should not
cause any SQL injection issues.
Of course this would break any code where people try to insert an
integer into a string column. But I think this would be very rare and
the benefit would out weight the disadvantages.
Previous Comments:
[2007-03-23 15:12:20] [EMAIL PROTECTED]
Emulation is wrong if it doesn't work. Numbers after LIMIT should not
be quoted.
[2007-03-07 09:54:18] [EMAIL PROTECTED]
Use PDO::ATTR_EMULATE_PREPARES = false to turn off emulation of
prepared statements.
PDO_MYSQL uses it by default because native prepared statements in
MySQL are quite limited - you can't use SHOW statements, for example.
The documentation should mention it, though.
Reclassified as docu problem.
[2007-03-06 17:13:44] phpbugs at filofox dot com
Description:
The following emerged after upgrading from 5.2.0 to 5.2.1 and has been
checked in both versions: the error only occurs in 5.2.1 .
When passing parameters into a LIMIT clause using PDO::execute(), it
appears that PDO is quoting the parameters, which causes MYSQL to throw
an error.
FYI: PDO_MYSQL is built against MySQL client library 5.0.18.
Reproduce code:
---
$dbh = new PDO('mysql:localhost;dbname=my_db', 'user', '' );
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try{
$query = $dbh-prepare( 'SELECT * FROM some_table LIMIT :start,
:limit' );
if ( $query-execute ( array ( 'start' = 0, 'limit' = 10 ) ) )
{
while ( $row = $query-fetch ( PDO::FETCH_ASSOC ) )
{
print_r($row);
}
$query-closeCursor();
}
} catch( Exception $e ){
print_r( $e );
}
Expected result:
A number of rows are returned.
Actual result:
--
An exception is thrown:
PDOException Object
(
[message:protected] = SQLSTATE[42000]: Syntax error or access
violation: 1064 You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to
use near ''0', '10'' at line 1
[string:private] =
[code:protected] = 42000
[file:protected] = [my_file].php
[line:protected] = 19
[trace:private] = Array
(
[0] = Array
(
[file] = [my_file].php
[line] = 19
[function] = execute
[class] = PDOStatement
[type] = -
[args] = Array
(
[0] = Array
(
[start] = 0
[limit] = 10
)
)
)
)
[errorInfo] = Array
(
[0] = 42000
[1] = 1064
[2] = You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near ''0', '10'' at line 1
)
)
--
Edit this bug report at http://bugs.php.net/?id=40740edit=1
#36226 [NoF-Opn]: Inconsistent handling when passing potential arrays.
ID: 36226
Updated by: [EMAIL PROTECTED]
Reported By: say_ten at multiplay dot co dot uk
-Status: No Feedback
+Status: Open
Bug Type: SOAP related
Operating System: FreeBSD 6.0-p4
PHP Version: 5.1.2
Assigned To: dmitry
New Comment:
Ah ok .. I finally had the genius idea of searching the existing test
cases for one that covers my issues. Since I am a phpt n00b, I ripped
the code instead of simply updating the test case. The code should be
similar enough for you to recognize from the test case for Bug
#36226.#13;#10;#13;#10;http://pooteeweet.org/public/SOAP_SINGLE_ELEMENT_ARRAYS.phps#13;#10;#13;#10;I
did a minor change to the wsdl to allow nillable for the
sequence.#13;#10;#13;#10;http://pooteeweet.org/public/bug35142.wsdl#13;#10;#13;#10;Would
be nice to have that one fixed for php 5.2.2.#13;#10;#13;#10;So the
issue is that I end up with an array(null) for logOnEvent instead of
simply null.
Previous Comments:
[2007-02-23 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2007-02-15 15:47:30] [EMAIL PROTECTED]
Could you please provide a working example with expected output. I
cannot imagine the situation when ext/soap will return array(null) for
unexisting XML elements.
[2007-02-08 15:32:19] [EMAIL PROTECTED]
Enabling this feature seems to result in giving me an array(null) if I
have a nill'ed sequence. Not sure if this is why you originally
introduced the feature of not returning single element sequences as
array's, but I was hoping to get an empty array in the above case.
[2006-02-02 12:42:40] [EMAIL PROTECTED]
This is not a bug but feature.
I stayed the default behavior unchanged, but added ability to create
arrays even if only one element exists.
To create arrays with single element, you should use special option in
SoapServer/SoapClient constructor.
$x = new SoapClient($wsdl, array('features' =
SOAP_SINGLE_ELEMENT_ARRAYS));
Fixed in CVS HEAD and PHP_5_1.
[2006-01-31 15:45:34] [EMAIL PROTECTED]
Assigned to the maintainer.
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/36226
--
Edit this bug report at http://bugs.php.net/?id=36226edit=1
#34657 [Opn]: If you get a communication problem when loading the WSDL, it fatal's
ID: 34657
Updated by: [EMAIL PROTECTED]
Reported By: gareth at wsys dot co dot uk
Status: Open
Bug Type: SOAP related
Operating System: Windows, Linux
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
In general nothing in ext/soap should be fatal if its not within the
control of the local php application. This means missing WSDL, changes
to the WSDL etc. All of this needs to be catchable in some way or
another (exception, returning false .. etc).
Also if an exception is thrown no warnings should be thrown for the
same issue.
Previous Comments:
[2007-01-15 15:53:18] jhendric at sierra-bravo dot com
Similar problem here with PHP 5.1.6.
try {
$soap = new SoapClient('[...]', array('exceptions' = true)); //
Note: Same results without or without exceptions = true
} catch(Exception $e) {
var_dump($e);
}
Results in:
Warning: SoapClient::__construct([...])
[function.SoapClient---construct]: failed to open stream: HTTP request
failed! HTTP/1.1 404 Not Found in [...]
Warning: SoapClient::__construct() [function.SoapClient---construct]:
I/O warning : failed to load external entity ... in [...]
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from '[...]' in
[...]
[2006-12-21 23:32:24] [EMAIL PROTECTED]
I get 3 warning + a SoapFault exception when running Lukas' test case
there. The output is:
Warning: SoapClient::SoapClient(): php_network_getaddresses:
getaddrinfo failed: Name or service not known in
/home/ek/projects/php_5_2/t on line 4
Warning: SoapClient::SoapClient(http://i_dont_exist.com/some.wsdl):
failed to open stream: No such file or directory in
/home/ek/projects/php_5_2/t on line 4
Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity http://i_dont_exist.com/some.wsdl; in
/home/ek/projects/php_5_2/t on line 4
string(9) SoapFault
NULL
I think getting 3 warning and an exception for failing to load WSDL
file is a bit excessive though :)
[2006-12-19 14:10:44] [EMAIL PROTECTED]
I can reproduce this error with php 5.1.4 and 5.2.0 on windows. And it
seems Derick was also able to reproduce it on Linux. Using the
following we get 3 warnings and a fatal error:
?php
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl');
} catch (SoapFault $e) {
var_dump(get_class($e));
} catch (Exception $e) {
var_dump(get_class($e));
}
var_dump($client);
It really should not do anything but throw an exception, as this is
what is defined to happen for fatal errors in constructors for all
extensions.
[2006-09-12 09:56:52] gareth at wsys dot co dot uk
OK, the debug information shows that the Soap client class is now
throwing an uncaught SoapFault exception (which causes the fatal
error).
with a try{ } catch(SoapFault $exception) I can continue the script.
I've closed the bug.
[2006-09-12 08:56:12] [EMAIL PROTECTED]
I cannot reproduce the bug even with 5.1.4. Try php -d log_errors=0
test.php. May be you are seeing log message and don't see Error
Caught after it?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34657
--
Edit this bug report at http://bugs.php.net/?id=34657edit=1
#30329 [Csd-Opn]: Error Fetching http body, No Content-Length, connection closed or chunked data
ID: 30329 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: SOAP related Operating System: Solaris 9 PHP Version: 5.0.2 Assigned To: dmitry New Comment: I am seeing the same issue on PHP 5.1.6 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Set-Cookie: JSESSIONID=DB0CD599DFF853F3A04B4B64819C4A7A; Path=/ Content-Type: text/xml;charset=UTF-8 Transfer-Encoding: chunked Date: Thu, 15 Feb 2007 09:11:56 GMT 176 env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/' Previous Comments: [2004-12-01 19:48:15] [EMAIL PROTECTED] Works fine. You even found the new URL of weservice during testing with our application server... :) -- Uwe [2004-12-01 19:23:25] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_0. [2004-10-05 15:02:48] [EMAIL PROTECTED] incorrect. The EAServer does respond with HTTP/1.0. And in HTTP/1.0 you can leave out the Content-Length (if unknown), because chunked encoding cannot be used with 1.0 [2004-10-05 14:50:22] [EMAIL PROTECTED] I don't think we should add workarounds around other buggy products. This is violating the RFC iirc. [2004-10-05 14:45:17] [EMAIL PROTECTED] The problem also sometimes occurs even with HTTP/1.0. After checking this, it seems that EAServer does not send a Content-Length! Can we change this in a way that get_http_body also accepts a zero content-length? 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/30329 -- Edit this bug report at http://bugs.php.net/?id=30329edit=1
#36226 [Csd-Opn]: Inconsistent handling when passing potential arrays.
ID: 36226
Updated by: [EMAIL PROTECTED]
Reported By: say_ten at multiplay dot co dot uk
-Status: Closed
+Status: Open
Bug Type: SOAP related
Operating System: FreeBSD 6.0-p4
PHP Version: 5.1.2
Assigned To: dmitry
Previous Comments:
[2007-02-08 15:32:19] [EMAIL PROTECTED]
Enabling this feature seems to result in giving me an array(null) if I
have a nill'ed sequence. Not sure if this is why you originally
introduced the feature of not returning single element sequences as
array's, but I was hoping to get an empty array in the above case.
[2006-02-02 12:42:40] [EMAIL PROTECTED]
This is not a bug but feature.
I stayed the default behavior unchanged, but added ability to create
arrays even if only one element exists.
To create arrays with single element, you should use special option in
SoapServer/SoapClient constructor.
$x = new SoapClient($wsdl, array('features' =
SOAP_SINGLE_ELEMENT_ARRAYS));
Fixed in CVS HEAD and PHP_5_1.
[2006-01-31 15:45:34] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-31 13:24:23] say_ten at multiplay dot co dot uk
Description:
When using the following WSDL reponse the server is allowed to return 0
to many recipes.
xsd:complexType name=getRecipesResponse_t
xsd:sequence
xsd:element name=recipes type=types:Recipe minOccurs=0
maxOccurs=unbounded /
/xsd:sequence
/xsd:complexType
The code returned from the function would be of the type:
array( array( id = 3, recipe = cake, description = desc )
);
If their is only 1 recipe the client returns a standard object of the
recipe. If there's more than one, the client returns an array of
recipes. This inconsitency results in code to detect and wrap the std
class into an array for compatibility with the following code,
foreach() for example. This is also true when passing arrays of arrays
to the SOAP server.
Expected result:
I would expect the single element arrays passed in to remain single
element arrays at the other end.
--
Edit this bug report at http://bugs.php.net/?id=36226edit=1
#36226 [Csd]: Inconsistent handling when passing potential arrays.
ID: 36226
Updated by: [EMAIL PROTECTED]
Reported By: say_ten at multiplay dot co dot uk
Status: Closed
Bug Type: SOAP related
Operating System: FreeBSD 6.0-p4
PHP Version: 5.1.2
Assigned To: dmitry
New Comment:
Enabling this feature seems to result in giving me an array(null) if I
have a nill'ed sequence. Not sure if this is why you originally
introduced the feature of not returning single element sequences as
array's, but I was hoping to get an empty array in the above case.
Previous Comments:
[2006-02-02 12:42:40] [EMAIL PROTECTED]
This is not a bug but feature.
I stayed the default behavior unchanged, but added ability to create
arrays even if only one element exists.
To create arrays with single element, you should use special option in
SoapServer/SoapClient constructor.
$x = new SoapClient($wsdl, array('features' =
SOAP_SINGLE_ELEMENT_ARRAYS));
Fixed in CVS HEAD and PHP_5_1.
[2006-01-31 15:45:34] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-31 13:24:23] say_ten at multiplay dot co dot uk
Description:
When using the following WSDL reponse the server is allowed to return 0
to many recipes.
xsd:complexType name=getRecipesResponse_t
xsd:sequence
xsd:element name=recipes type=types:Recipe minOccurs=0
maxOccurs=unbounded /
/xsd:sequence
/xsd:complexType
The code returned from the function would be of the type:
array( array( id = 3, recipe = cake, description = desc )
);
If their is only 1 recipe the client returns a standard object of the
recipe. If there's more than one, the client returns an array of
recipes. This inconsitency results in code to detect and wrap the std
class into an array for compatibility with the following code,
foreach() for example. This is also true when passing arrays of arrays
to the SOAP server.
Expected result:
I would expect the single element arrays passed in to remain single
element arrays at the other end.
--
Edit this bug report at http://bugs.php.net/?id=36226edit=1
#34657 [Csd-Opn]: If you get a communication problem when loading the WSDL, it fatal's
ID: 34657
Updated by: [EMAIL PROTECTED]
Reported By: gareth at wsys dot co dot uk
-Status: Closed
+Status: Open
Bug Type: SOAP related
Operating System: Windows, Linux
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
I can reproduce this error with php 5.1.4 and 5.2.0 on windows. And it
seems Derick was also able to reproduce it on Linux. Using the
following we get 3 warnings and a fatal error:
?php
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl');
} catch (SoapFault $e) {
var_dump(get_class($e));
} catch (Exception $e) {
var_dump(get_class($e));
}
var_dump($client);
It really should not do anything but throw an exception, as this is
what is defined to happen for fatal errors in constructors for all
extensions.
Previous Comments:
[2006-09-12 09:56:52] gareth at wsys dot co dot uk
OK, the debug information shows that the Soap client class is now
throwing an uncaught SoapFault exception (which causes the fatal
error).
with a try{ } catch(SoapFault $exception) I can continue the script.
I've closed the bug.
[2006-09-12 08:56:12] [EMAIL PROTECTED]
I cannot reproduce the bug even with 5.1.4. Try php -d log_errors=0
test.php. May be you are seeing log message and don't see Error
Caught after it?
[2006-09-11 07:50:34] gareth at wsys dot co dot uk
I have tried to use set_error_handler(), but as you know it cannot
catch fatal errors.
Does anyone else have a workaround?
[2006-09-08 21:50:38] [EMAIL PROTECTED]
See also bug #38703.
[2006-09-06 10:40:10] gareth at wsys dot co dot uk
Have tried on PHP version 5.1.6, still getting the following error:
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://urlhere.com/file.wsdl'.
So I still cannot catch this error, which limits my use of SOAP as it
will kill my script.
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/34657
--
Edit this bug report at http://bugs.php.net/?id=34657edit=1
#36750 [WFx]: pg_field_table does not exists
ID: 36750 Updated by: [EMAIL PROTECTED] Reported By: fabrizio dot balliano at crealabs dot it Status: Wont fix Bug Type: PostgreSQL related Operating System: irrelevant PHP Version: 4.4.2 New Comment: Looking at the libpg docs: http://www.postgresql.org/docs/8.1/interactive/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO PQftable Returns the OID of the table from which the given column was fetched. Column numbers start at 0. Oid PQftable(const PGresult *res, int column_number); InvalidOid is returned if the column number is out of range, or if the specified column is not a simple reference to a table column, or when using pre-3.0 protocol. You can query the system table pg_class to determine exactly which table is referenced. The type Oid and the constant InvalidOid will be defined when you include the libpq header file. They will both be some integer type. Previous Comments: [2006-03-15 23:53:16] [EMAIL PROTECTED] The PostgreSQL API does not support this functionality. [2006-03-15 21:41:16] fabrizio dot balliano at crealabs dot it Description: function pg_field_table is not implemented but I think it's important, it's present for other db, such as mysql (http://php.net/mysql_field_table) -- Edit this bug report at http://bugs.php.net/?id=36750edit=1
#35386 [Opn-Asn]: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
Reported By: slapaf at hotmail dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5.1.0
Assigned To: abies
Previous Comments:
[2006-01-02 10:17:34] slapaf at hotmail dot com
The result is the same using dev-version.
[0]=
array(2) {
[EVENT_NAME]=
NULL
[0]=
NULL
}
[1]=
array(2) {
[EVENT_NAME]=
string(6) name 3
[0]=
string(6) name 3
}
[2]=
array(2) {
[EVENT_NAME]=
string(6) name 4
[0]=
string(6) name 4
}
[3]=
array(2) {
[EVENT_NAME]=
string(6) name 5
[0]=
string(6) name 5
}
[2005-12-30 01:00:05] 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-12-22 10:38:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-11-25 11:58:10] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-25 11:55:38] slapaf at hotmail dot com
deleting row with name 1 and inserting a name 5 returns:
NULL :
string : name 3
string : name 4
string : name 5
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35386
--
Edit this bug report at http://bugs.php.net/?id=35386edit=1
#35488 [Opn]: serialize() segmentation fault (works fine in PHP 5.1)
ID: 35488 Updated by: [EMAIL PROTECTED] Reported By: kenashkov at gmail dot com Status: Open Bug Type: Strings related Operating System: Fedora Core 4 PHP Version: 4.4.1 New Comment: Probably a dube of http://bugs.php.net/bug.php?id=35277 Previous Comments: [2005-11-30 13:58:20] kenashkov at gmail dot com Description: Segmentation fault when serializing multidimentional recursive arrays. The code below works fine with 4.3.11 (again on FC4). When the argument is passend by reference (which is deprecated): print_r(unserialize(serialize($arr1))); it is fine. Or passing a reference: print_r(unserialize(serialize($ref=$arr1))); also works. No problem with serializing just $arr1[0]=$arr; Reproduce code: --- ? $arr1[0][0] = $arr1; print_r(unserialize(serialize($arr1))); ? Expected result: Array ( [0] = Array ( [0] = Array ( [0] = Array ( [0] = Array *RECURSION* ) ) ) ) Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=35488edit=1
#27508 [Csd]: feof() broken for user-defined streams
ID: 27508 Updated by: [EMAIL PROTECTED] Reported By: adam at trachtenberg dot com Status: Closed Bug Type: Network related Operating System: * PHP Version: 5CVS-2005-03-24 Assigned To: wez New Comment: This bug will actually not be fixed in 5.0.x but instead will only be fixed in 5.1.x and above. Please use version_compare() to handle this problem. Previous Comments: [2005-05-11 04:02:58] [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. Fixed in HEAD. [2004-03-09 11:32:53] adam at trachtenberg dot com Oops. Wrong file extension. Should be: http://www.trachtenberg.com/patches/bug27508.txt [2004-03-09 11:31:38] adam at trachtenberg dot com Here's an example where the class is just a wrapper around fopen(), fread(), fwrite(), etc. It's at http://www.trachtenberg.com/patches/ bug27508.php. In PHP 4, you get: line1 line2 line3 PHP 5 outputs no data. [2004-03-09 08:47:27] [EMAIL PROTECTED] Wez, the fix didn't quite fix it. Adam, can you please come up with a test case and send it to internals@ ? (The one in manual is a bit long, could it be made any shorter?) [2004-03-05 16:05:11] adam at trachtenberg dot com Description: It looks like feof() doesn't work correctly in all cases for user-defined streams. It seems like the class stream_eof() method is not being called when feof() is invoked in PHP. This works correctly using 4.3.5RC3, but not PHP 5 current CVS. It also works correctly if I do an fpassthru() on the file pointer and let PHP handle the feof() check. Reproduce code: --- See VariableStream class in the manual: http://us2.php.net/manual/en/function.stream-wrapper-register.php In particular the while(!feof()) bit. Expected result: line1 line2 line3 string(18) line1 line2 line3 (This is what I get from PHP 4.3.5RC3) Actual result: -- string(18) line1 line2 line3 -- Edit this bug report at http://bugs.php.net/?id=27508edit=1
#34168 [Csd]: XML error: not well-formed (invalid token)
ID: 34168 Updated by: [EMAIL PROTECTED] Reported By: dexter at debian dot org Status: Closed Bug Type: Compile Failure Operating System: Debian Linux PHP Version: 5CVS-2005-08-17 (snap) Assigned To: pajoye New Comment: http://pear.php.net/bugs/bug.php?id=5123 Previous Comments: [2005-08-17 14:31:51] [EMAIL PROTECTED] PEAR bugs, moved to pear.php.net/bugs [2005-08-17 12:41:56] dexter at debian dot org Description: $ sapi/cli/php -n -C -q -d include_path=../pear ../pear/scripts/pearcmd.php -v -c $(pwd)/.pearrc install --installroot=$(pwd)/tmp-pear --force --nodeps ../pear/package-Archive_Tar.xml XML error: not well-formed (invalid token) at line 22 $ sed -n 22p ../pear/package-Archive_Tar.xml nameStig S#263;ther Bakken/name It seems that XML parser does not recognize encoding?! The previous PHP5.0.4 and php5.1.0b3 binaries work correctly. -- Edit this bug report at http://bugs.php.net/?id=34168edit=1
#29023 [Csd-Opn]: fread() only reads 8192 bytes from a local file
ID: 29023 Updated by: [EMAIL PROTECTED] Reported By: benjcarson at digitaljunkies dot ca -Status: Closed +Status: Open Bug Type: Filesystem function related Operating System: Linux PHP Version: 5CVS-2004-07-05 (dev) Assigned To: wez New Comment: I think there are a couple dupes (#32810, #32469, maybe even #30441) of this one. And on a recent win head snapshot it was still broken: php5-win32-200505191430 Previous Comments: [2004-07-10 12:57:28] [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-07-06 16:42:38] benjcarson at digitaljunkies dot ca While I realize that file_get_contents() is faster, the code that lead me to this bug was not my own. It was Smarty (2.6.2, although 2.6.3 has the same problem), which has worked very well with PHP5 until now. [2004-07-06 15:26:51] [EMAIL PROTECTED] I really can't see how this can be CORRECT behaviour as this has worked (like it says in docs too :) before just fine. OTOH, you should always use file_get_contents() instead anyway. :) [2004-07-06 09:14:52] [EMAIL PROTECTED] Assigning to Wez... although I'd say that this is *correct* behavior, it shouldn't cause a BC break. [2004-07-05 22:28:48] benjcarson at digitaljunkies dot ca Description: In the latest cvs snap, fread() does not read more than 8192 bytes from a local file, despite specifying a larger read size as the second parameter. If the fread() call is wrapped in a while (!feof) loop the file can be read correctly, but only 8k at a time. This contradicts the first example in the manual (http://www.php.net/manual/en/function.fread.php) and is a BC break. As far as I can tell the change was made sometime between the 2004-06-22 snap and the 2004-07-04 snap. I've tested both using my php.ini file and without (i.e. using the built-in defaults). I configured using the following command: ./configure --prefix=/usr --with-apxs=/usr/bin/apxs \ --enable-memory-limit \ --with-layout-GNU\ --enable-bcmath \ --enable-calendar \ --with-curl=/usr \ --enable-exif \ --enable-ftp \ --enable-mbstring \ --enable-shmop \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-bz2 \ --with-config-file-path=/etc/php5/apache \ --with-gd=/usr \ --with-freetype-dir=shared,/usr \ --with-jpeg-dir=/usr \ --with-png-dir=shared,/usr \ --with-ttf=shared,/usr \ --with-xpm-dir=shared,/usr/X11R6 \ --with-gettext \ --with-kerberos=/usr \ --with-ldap=shared,/usr \ --with-mhash=shared,/usr \ --with-mm \ --with-ncurses=/usr \ --with-openssl=/usr \ --with-pcre-regex=/usr \ --with-pear \ --with-pgsql \ --with-pspell=/usr \ --with-zlib \ --with-zlib-dir=/usr Reproduce code: --- #!/usr/bin/php ?php $filename = /some/largish/local/file; $fd = fopen($filename, 'r'); $contents = fread($fd, filesize($filename)); echo strlen($contents) .\n; fclose($fd); ? Expected result: (the file's actual size, in bytes) Actual result: -- 8192 -- Edit this bug report at http://bugs.php.net/?id=29023edit=1
#32810 [Asn]: fread after tmpfile() reads only 8192 bytes
ID: 32810
Updated by: [EMAIL PROTECTED]
Reported By: matteo at beccati dot com
Status: Assigned
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-04-24)
Assigned To: wez
New Comment:
php5-win32-200505191430 is still suffering from this.
Previous Comments:
[2005-04-24 16:40:51] [EMAIL PROTECTED]
Wez breaks, Wez fixes. (Streams stuff broke this)
[2005-04-24 16:04:54] matteo at beccati dot com
Description:
In recent PHP versions, fread only reads 8192 bytes from a file
generated with tmpfile().
I've already seen bug reports #29023 and #30936 which seem strongly
related to this issue. From what I can see, fread on local files isn't
limited to the PHP chunk size of 8192, while a fread on a tmpfile acts
like it was i.e. a network stream, breaking backwards compatibility. I
found out this issue investigating a recently reported bug for
phpAdsNew, which uses this function to deal with remote ftp-stored
files.
IMVHO this can be considered a bug in in the tmpfile() implementation.
If you don't agree, well... I suggest to mark it as a documentation
bug, because I couldn't find nothing related to the 8192 bytes limit in
the manual.
Versions/OS tested and affected:
PHP 4.3.10 Linux
PHP 4.3.11 FreeBSD and Windows
PHP 5.0.4 Windows
Versions/OS tested and unaffected:
PHP 4.3.4 Windows
Reproduce code:
---
?php
$fp = tmpfile();
// This would give the correct result
// $fp = fopen('/tmp/test.dat', 'w+');
fwrite($fp, str_repeat('0', 10));
$size = ftell($fp);
rewind($fp);
$buf = fread($fp, $size);
echo Bytes written: .$size.\n;
echo Bytes read:.strlen($buf).\n;
fclose($fp);
?
Expected result:
Bytes written: 10
Bytes read:10
Actual result:
--
Bytes written: 10
Bytes read:8192
--
Edit this bug report at http://bugs.php.net/?id=32810edit=1
#30934 [Asn]: Special keyword 'self' inherited in child classes
ID: 30934 Updated by: [EMAIL PROTECTED] Reported By: jbs at fromru dot com Status: Assigned Bug Type: Class/Object related Operating System: * PHP Version: 5.0.3 Assigned To: andi New Comment: I think this really needs to be addressed. For example the php manual features a sample singleton implementation: http://www.php.net/manual/en/language.oop5.patterns.php Now how would one go about making it possible to extend the Example class without having to cut and paste the singleton() method to this extended class (one would probably also need to the instance property to hold an array of instances keyed be the class name)? Not exactly in the spirit of OOP imho. It seems to me the best solution to retain this speed optimization of resolving these things at compile time is to copy the implementations of static items over to classes that extend that class before this evaluation is done. Just a thought from an outside perspective, dunno if this is feasible however in the ZE2 implementation. Previous Comments: [2005-04-11 23:14:42] aknaub at 3st dot de Sorry, but this quote is nonsense. Every real OOP language (Ruby, ObjC etc.) resolves static methods at runtime. [2005-04-11 13:50:15] jbs at fromru dot com I've noticed some similar reports. For example, the one at http://bugs.php.net/bug.php?id=30235. Here is a quote: Sorry, you have a complete wrong idea og OO programming. Static methods are bound/resolved at compile time. That is the compiler can replace self with the current class. So, it appears as it is a limitation of the compiler and the entire object model. I think such behavior makes inheritance of static methods useless because even if a static method is inherited, it still functions as in the class where it was declared. Moreover, inherited static methods are using the static properties which were declared in the parent class but not the inherited one. So, in my opinion self keyword should be replaced with the name of the inherited class during compiling. Or at least a new magic keyword should be added and named like this, for example. [2005-03-30 23:47:28] [EMAIL PROTECTED] Andi, is this a bug or not? [2005-03-29 09:10:20] aknaub at 3st dot de I reproduced the bug with snapshot php5-200503282030, compiled as cli on Mac OS X 10.3.8. [2005-03-27 01:18:39] mongole at tuivelsminne dot at I reproduced the bug with snapshot php5-200503262330, compiled as mod_php in apache-1.3.33 on FC 3. 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/30934 -- Edit this bug report at http://bugs.php.net/?id=30934edit=1
#24278 [Opn-Fbk]: error while trying to save LOB
ID: 24278
Updated by: [EMAIL PROTECTED]
Reported By: trent at low dot ru
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: Linux, Win32
PHP Version: 4CVS-2003-08-15 (stable)
New Comment:
Have you tried using the sample code provided in the php manual?
http://www.php.net/manual/en/function.ocinewdescriptor.php
Previous Comments:
[2003-06-21 10:28:43] trent at low dot ru
Description:
I got these errors while trying to inputing string to LOB using LOB's
method save(); :
Warning: save() [function.save.html]: OCILobWrite: OCI_INVALID_HANDLE
in /www/sample.php on line 15
Warning: load() [function.load.html]: OCILobGetLength:
OCI_INVALID_HANDLE in /www/sample.php on line 19
This was tested with:
4.3.1-win32
4.3.1-linux
Latest snapshot on Linux.
Note: in oracle function there is in/out parameter used.
Additional exception from Oracle: ORA-22275: invalid LOB locator
specified.
Reproduce code:
---
//logging in
$conn = OCILogon('user', 'pass', 'srvname');
//creating new LOB locator
$clob = OCINewDescriptor($conn, OCI_D_LOB);
$sql = 'begin :ret:=test(lob_object=:lob_object_param); end;';
//parsing query - ok
$stmt = OCIParse($conn, $sql);
//binding variables - ok
OCIBindByName($stmt, ':lob_object_param', $clob, -1, OCI_B_CLOB);
OCIDefineByName($stmt, ':lob_object_param', $clob, OCI_B_CLOB);
OCIBindByName($stmt, ':ret', $return, 4);
OCIExecute($stmt, OCI_DEFAULT);
if($clob-save($param)) { // Warning: OCILobWrite: OCI_INVALID_HANDLE
in sample.php on line 15
OCICommit($conn); // this warning appears only when using method
save(); of LOB locator
}
print $clob-load(); // Warning: OCILobGetLength: OCI_INVALID_HANDLE
in sample.php on line 19
// when using load method in LOB locator
$clob-free();
OCIFreeStatement($stmt);
Expected result:
I'm trying to save string as CLOB using Oracle function.
I do expect it to work fine =)
Maybe I'm doing something extremely wrong?
If so, please, correct me.
Thanx in advance.
--
Edit this bug report at http://bugs.php.net/?id=24278edit=1
#18670 [Opn-Fbk]: strtotime() bug
ID: 18670
Updated by: [EMAIL PROTECTED]
Reported By: nic at bbmcarlson dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Linux
PHP Version: 4.3.3RC5-dev
New Comment:
well atleast on php 4.3.3 2 and next seem to be working as expected
in returning the same results using the script provided by spud at
nothingness dot org.
the comment by mphillips at lufkin dot org is unrelated to the bug
report and is actually not a bug anyways since the format is not
supported (with '/' as separators it works as expected)
finally going by the manual this behaviour described by the bug report
may be inconvinient but not really counter the documentation: The unit
of time displacement may be selected by the string `year' or `month'
for moving by whole years or months. These are fuzzy units, as years
and months are not all of equal duration. More precise units are
`fortnight' which is worth 14 days, `week' worth 7 days, `day' worth 24
hours, `hour' worth 60 minutes, `minute' or `min' worth 60 seconds, and
`second' or `sec' worth one second. An `s' suffix on these units is
accepted and ignored.
i lack the confidence to mark this report as bogus so i am just marking
it as feedback :-)
Previous Comments:
[2003-02-11 14:12:37] mphillips at lufkin dot org
I have noticed that when you do something like
$sdate = date9'Y-m-d', strtotime('02-09-2003'));
$sdate is getting '2008-02-24'.
Is this a common occurance
[2002-10-31 12:07:20] matt at codewalkers dot com
I also can confirm that strtotime acts funny when the same day does not
exist in the next month:
?
$timestamp = strtotime(31 October 2002);
$next_month = strftime(%B ,strtotime(+1 month, $timestamp));
echo $next_month;
?
displays:
December
[2002-09-24 17:07:42] spud at nothingness dot org
In PHP 4.2.3, the difference between 2 and next are still screwy in
strtotime(). I'm trying to parse icalendar recurrence formats, so I
need to calculate things like the second Monday in a month. Sample
code below illustrates the difference between 2 and next (which
should be identical).
?
$start = strtotime('September 1, 2002');
echo ('Start timestamp: '.$start.'br');
echo ('Start date: Sunday, Sep 1 2002br');
$first = strtotime('first Monday',$start);
echo ('First Monday: '.date('l, M d Y',$first).'br');
$oneth = strtotime('1 Monday',$start);
echo ('1 Monday: '.date('l, M d Y',$oneth).'br');
$next = strtotime('next Monday',$start);
echo ('Next Monday: '.date('l, M d Y',$next).'br');
$twoth = strtotime('2 Monday',$start);
echo ('2 Monday: '.date('l, M d Y',$twoth).'br');
$third = strtotime('third Monday',$start);
echo ('Third Monday: '.date('l, M d Y',$third).'br');
$threeth = strtotime('3 Monday',$start);
echo ('3 Monday: '.date('l, M d Y',$threeth).'br');
?
[2002-07-31 10:44:11] [EMAIL PROTECTED]
Sebastian, yes, that is because I changed how next works based on bug
report #18655
It works correctly for days now, but it does seem like month-handling
is messed up now.
[2002-07-31 10:39:10] [EMAIL PROTECTED]
The problem is that it adds a full month to the current timestamp. So
you end up getting the 31st of the next month and some months do not
have 31 days. I'll need to do some reading to determine if strtotime()
is supposed to pick the beginning of the next month instead, or perhaps
the middle.
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/18670
--
Edit this bug report at http://bugs.php.net/?id=18670edit=1
