[PHP-BUG] Bug #63684 [NEW]: pdo sqlite round function can't work correct
From: roastduck at qq dot com
Operating system: windows xp
PHP version: 5.3.19
Package: PDO related
Bug Type: Bug
Bug description:pdo sqlite round function can't work correct
Description:
when I used pdo for the sql "select round(863521.8, 2) as a", it
gets
wrong result 863521.78001
Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$st = $db->query('select round(863521.8, 2) as a');
$data = $st->fetchAll();
print_r($data);
$st = $db->query('select round(372366.57778, 2) as a');
$data = $st->fetchAll();
print_r($data);
Expected result:
Array
(
[0] => Array
(
[a] => 863521.78001
[0] => 863521.78001
)
)
Array
(
[0] => Array
(
[a] => 372366.58
[0] => 372366.58
)
)
--
Edit bug report at https://bugs.php.net/bug.php?id=63684&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63684&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63684&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63684&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63684&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63684&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63684&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63684&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63684&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63684&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63684&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63684&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63684&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63684&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63684&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63684&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63684&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63684&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63684&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63684&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63684&r=mysqlcfg
Bug #63684 [Opn->Nab]: pdo sqlite round function can't work correct
Edit report at https://bugs.php.net/bug.php?id=63684&edit=1
ID: 63684
Updated by: ahar...@php.net
Reported by:roastduck at qq dot com
Summary:pdo sqlite round function can't work correct
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: windows xp
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
Previous Comments:
[2012-12-04 08:40:02] roastduck at qq dot com
Description:
when I used pdo for the sql "select round(863521.8, 2) as a", it gets
wrong result 863521.78001
Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$st = $db->query('select round(863521.8, 2) as a');
$data = $st->fetchAll();
print_r($data);
$st = $db->query('select round(372366.57778, 2) as a');
$data = $st->fetchAll();
print_r($data);
Expected result:
Array
(
[0] => Array
(
[a] => 863521.78001
[0] => 863521.78001
)
)
Array
(
[0] => Array
(
[a] => 372366.58
[0] => 372366.58
)
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63684&edit=1
Bug #54955 [Com]: FastCGI doesn't recognize Windows relative paths
Edit report at https://bugs.php.net/bug.php?id=54955&edit=1 ID: 54955 Comment by: marc dot fauser+php at gmail dot com Reported by:johanntrg at msn dot com Summary:FastCGI doesn't recognize Windows relative paths Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows 7 64bits SP1 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I have the same problem since months. I would even pay money to get this bug fixed. So far you can "solve" it by using mklink. e.g. mklink /J files ..\files Previous Comments: [2011-05-30 22:08:30] johanntrg at msn dot com Description: I have configured my webserver (nginx) to have its document root out of its working path in "..\files" (please, note the two dots). When I request static files, it serves them without any problem. Anyway If I request a PHP file, the request it's not served because php-cgi.exe running as the fastCGI server al 127.0.0.1:9000 returns an error 400 code. If I user absolute paths it works. Also, if I move the "..\files" folder to "./files" (please, note the only one dot) and I change the document root to reflect that new relative path. So It looks that relative paths with two dots are not getting resolved by php- cgi.exe as fastCGI server. -- Edit this bug report at https://bugs.php.net/bug.php?id=54955&edit=1
[PHP-BUG] Req #63685 [NEW]: Make it easier to supply include paths on the CLI
From: alastair at propcom dot co dot uk Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Feature/Change Request Bug description:Make it easier to supply include paths on the CLI Description: C standard is to use -I to add an include path for header files. There are also the environment variables CPATH, C_INCLUDE_PATH and CPLUS_INCLUDE_PATH. Other languages follow suit. Python uses the PYTHONPATH environment variable. Perl uses PERL5LIB *and* -I, and also has a runtime 'use lib' too. PHP's current only way of doing it is to set the config itself (I didn't see anything about environment variables in the docs on include_path), which usually involves getting the config and manually merging the extras. Setting include paths is a much more common operation than the procedure to do so would suggest; it would be very helpful for this boilerplate code (get, merge, set) to be performed by PHP itself as a result of an option. -I is a good idea because it's established by C already, and hence maintains consistency. It would also be useful to honour an environment variable and possibly also a runtime function, just to make it easier. -- Edit bug report at https://bugs.php.net/bug.php?id=63685&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63685&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63685&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63685&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63685&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63685&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63685&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63685&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63685&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63685&r=support Expected behavior: https://bugs.php.net/fix.php?id=63685&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63685&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63685&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63685&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63685&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63685&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63685&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63685&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63685&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63685&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63685&r=mysqlcfg
Req #53648 [Com]: Allow __toString() to throw exceptions
Edit report at https://bugs.php.net/bug.php?id=53648&edit=1
ID: 53648
Comment by: benjamin dot morel at strictcoding dot co dot uk
Reported by:clicky at erebot dot net
Summary:Allow __toString() to throw exceptions
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
I strongly support this feature request.
I haven't read any valid supportive argument so far, for keeping this behaviour
as
it is currently.
In case someone would be worried about backward compatibility issues, this
change
could be introduced with the next major version, PHP 5.5!
I would be grateful if a member of the PHP team could review this request.
Previous Comments:
[2011-11-10 04:05:48] dqhendricks at hotmail dot com
this problem is causing me such a headache. i'm not even trying to convert an
object
to a string and i'm getting this error. the bug become such a pain to track. i
have
an active record that lazy loads child objects through __get. so even though im
just
trying to print a property of an object that is a string, the fact that a __get
is
used to get that object, prevents me from throwing exceptions. it looks like
this
echo $activerecord->childobject->somestring;
[2011-01-04 14:45:29] clicky at erebot dot net
Description:
Currently, when casting an object with __toString() to a string, __toString()
is not allowed to throw an exception.
Trying to do so triggers an E_ERROR "Method %s::__toString() must not throw an
exception".
IMHO, this is counter-intuitive, especially since calling that object's
__toString() method directly would correctly throw the exception.
I propose to allow __toString() to throw exceptions.
Note: this was already reported in http://bugs.php.net/bug.php?id=50699 but
marked as bogus with the only explanation being "__toString must not throw".
So, I'm marking this as a feature request rather than a bug, since the current
behaviour seems to be expected (though it is not documented in
http://php.net/manual/en/language.oop5.magic.php#language.oop5.magic.tostring).
I also found this entry
http://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring
which cites Johannes saying this requires major changes in the code. However,
the article mentioned is from 2007 and I think the limitations in ZE that
prevented this to be implemented were lifted since then.
I'm not very versed in PHP's inner workings, but attached is a tentative patch
which seems to fix this issue.
Test script:
---
Expected result:
object(CustomException)#2 (7) {
["message":protected]=>
string(5) "oops!"
["string":"Exception":private]=>
string(0) ""
["code":protected]=>
int(0)
["file":protected]=>
string(17) "/tmp/toString.php"
["line":protected]=>
int(65)
["trace":"Exception":private]=>
array(1) {
[0]=>
array(6) {
["file"]=>
string(17) "/tmp/toString.php"
["line"]=>
int(71)
["function"]=>
string(10) "__toString"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(0) {
}
}
}
["previous":"Exception":private]=>
NULL
}
Actual result:
--
PHP Fatal error: Method Foo::__toString() must not throw an exception in
/tmp/toString.php on line 0
PHP Stack trace:
PHP 1. {main}() /tmp/toString.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=53648&edit=1
Bug #50699 [Com]: Cannot throw Exceptions in __toString()
Edit report at https://bugs.php.net/bug.php?id=50699&edit=1 ID: 50699 Comment by: benjamin dot morel at strictcoding dot co dot uk Reported by:gmblar+php at gmail dot com Summary:Cannot throw Exceptions in __toString() Status: Not a bug Type: Bug Package:*General Issues Operating System: * PHP Version:5.3.1 Block user comment: N Private report: N New Comment: @bjori The documentation does not say that __toString() must not throw an exception. The fact is, this is currently an undocumented behaviour, that could therefore be changed without causing much pain (we're supposed to write code based on the documented behaviour of a function, not its side effects): http://php.net/manual/en/language.oop5.magic.php#object.tostring A feature request has been open, I would be grateful if you could give your opinion there, especially now than PHP 5.5 is being developed: https://bugs.php.net/bug.php?id=53648 Thank you. Previous Comments: [2010-01-08 22:51:46] gmblar+php at gmail dot com Current behavior of __toString is crap. Why i can use trigger_error() bug not throw Exception() in __toString()? Please fix it. [2010-01-08 22:24:09] bj...@php.net 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 __toString() must not throw exceptions [2010-01-08 22:22:35] gmblar+php at gmail dot com Description: Cannot throw Exceptions in __toString(). Instead it produces a Fatal error. Reproduce code: --- Expected result: Fatal error: Uncaught exception 'Exception' with message 'Incomplete Data' in /-:6 Actual result: -- Fatal error: Method bar::__toString() must not throw an exception in /- on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=50699&edit=1
Bug #63528 [Asn->Csd]: Generators crash on Zend\tests\generators\clone_with_stack.phpt
Edit report at https://bugs.php.net/bug.php?id=63528&edit=1 ID: 63528 Updated by: a...@php.net Reported by:a...@php.net Summary:Generators crash on Zend\tests\generators\clone_with_stack.phpt -Status: Assigned +Status: Closed Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.5Git-2012-11-15 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed with these two commits: https://github.com/php/php-src/commit/66b8ece02a9592fb70d1ca2990614004858c4e8b https://github.com/php/php-src/commit/70f83f35d089d0cafae12ae231a38541f5c8e41c Previous Comments: [2012-12-03 15:51:53] ni...@php.net @ab: I just tried the current build (php-5.5-nts-windows-vc9-x86-r262decd) and this does not occur anymore. I think that dmitry's changes fixed this as a side effect. Does the issue persist for you? [2012-12-03 14:22:17] a...@php.net nikic, any progress on this one? [2012-11-22 20:31:41] a...@php.net No, only the mentioned test fails for me. Newly tested with both TS and NTS snaps from Nov 22th http://windows.php.net/downloads/snaps/php-5.5/ . A way to repro your fails? [2012-11-21 12:04:07] ni...@php.net Is this the only test that is failing for you? I just played around with it on Windows and for me anything involving pushed stack arguments crashes. E.g. the yield_during_function_call test. [2012-11-15 15:57:05] a...@php.net Btw. there are no valgrind complains on Linux for this test. 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=63528 -- Edit this bug report at https://bugs.php.net/bug.php?id=63528&edit=1
[PHP-BUG] Bug #63686 [NEW]: Build with --enable-dtrace fails
From: d...@php.net Operating system: Solaris PHP version: 5.5Git-2012-12-04 (Git) Package: *General Issues Bug Type: Bug Bug description:Build with --enable-dtrace fails Description: building with --enable-dtrace results in Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) which was introduced in commit 70f83f35d089d0cafae12ae231a38541f5c8e41c Author: Dmitry Stogov Date: Fri Nov 30 13:39:23 2012 +0400 Test script: --- ./buildconf ./configure --enable-dtrace make Expected result: build complete Actual result: -- /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_get_executed_filenameâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_executeâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing argument 1 of âget_active_class_nameâ from incompatible pointer type [enabled by default] In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0, from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22: /home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected âconst char **â but argument is of type âchar **â /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend.c: In function âzend_startupâ: /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared identifier is reported only once for each function it appears in make: *** [Zend/zend.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit bug report at https://bugs.php.net/bug.php?id=63686&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63686&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63686&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63686&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63686&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63686&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63686&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63686&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63686&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63686&r=support Expected behavior: https://bugs.php.net/fix.php?id=63686&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63686&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63686&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63686&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63686&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63686&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63686&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63686&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63686&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63686&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63686&r=mysqlcfg
Bug #63686 [Opn->Asn]: Build with --enable-dtrace fails
Edit report at https://bugs.php.net/bug.php?id=63686&edit=1 ID: 63686 Updated by: d...@php.net Reported by:d...@php.net Summary:Build with --enable-dtrace fails -Status: Open +Status: Assigned Type: Bug Package:*General Issues Operating System: Solaris PHP Version:5.5Git-2012-12-04 (Git) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2012-12-04 14:34:28] d...@php.net Description: building with --enable-dtrace results in Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) which was introduced in commit 70f83f35d089d0cafae12ae231a38541f5c8e41c Author: Dmitry Stogov Date: Fri Nov 30 13:39:23 2012 +0400 Test script: --- ./buildconf ./configure --enable-dtrace make Expected result: build complete Actual result: -- /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_get_executed_filenameâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_executeâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing argument 1 of âget_active_class_nameâ from incompatible pointer type [enabled by default] In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0, from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22: /home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected âconst char **â but argument is of type âchar **â /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend.c: In function âzend_startupâ: /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared identifier is reported only once for each function it appears in make: *** [Zend/zend.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit this bug report at https://bugs.php.net/bug.php?id=63686&edit=1
Req #53648 [Com]: Allow __toString() to throw exceptions
Edit report at https://bugs.php.net/bug.php?id=53648&edit=1
ID: 53648
Comment by: ni...@php.net
Reported by:clicky at erebot dot net
Summary:Allow __toString() to throw exceptions
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
@benjamin: I don't think anyone opposes this feature request, it's just too
hard to implement. Allowing __toString to throw exceptions would require any
internal code doing a zval to string conversion to be exception-safe. See also:
http://markmail.org/message/lkpmpnhrvcbafhkd
Previous Comments:
[2012-12-04 12:57:36] benjamin dot morel at strictcoding dot co dot uk
I strongly support this feature request.
I haven't read any valid supportive argument so far, for keeping this behaviour
as
it is currently.
In case someone would be worried about backward compatibility issues, this
change
could be introduced with the next major version, PHP 5.5!
I would be grateful if a member of the PHP team could review this request.
[2011-11-10 04:05:48] dqhendricks at hotmail dot com
this problem is causing me such a headache. i'm not even trying to convert an
object
to a string and i'm getting this error. the bug become such a pain to track. i
have
an active record that lazy loads child objects through __get. so even though im
just
trying to print a property of an object that is a string, the fact that a __get
is
used to get that object, prevents me from throwing exceptions. it looks like
this
echo $activerecord->childobject->somestring;
[2011-01-04 14:45:29] clicky at erebot dot net
Description:
Currently, when casting an object with __toString() to a string, __toString()
is not allowed to throw an exception.
Trying to do so triggers an E_ERROR "Method %s::__toString() must not throw an
exception".
IMHO, this is counter-intuitive, especially since calling that object's
__toString() method directly would correctly throw the exception.
I propose to allow __toString() to throw exceptions.
Note: this was already reported in http://bugs.php.net/bug.php?id=50699 but
marked as bogus with the only explanation being "__toString must not throw".
So, I'm marking this as a feature request rather than a bug, since the current
behaviour seems to be expected (though it is not documented in
http://php.net/manual/en/language.oop5.magic.php#language.oop5.magic.tostring).
I also found this entry
http://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring
which cites Johannes saying this requires major changes in the code. However,
the article mentioned is from 2007 and I think the limitations in ZE that
prevented this to be implemented were lifted since then.
I'm not very versed in PHP's inner workings, but attached is a tentative patch
which seems to fix this issue.
Test script:
---
Expected result:
object(CustomException)#2 (7) {
["message":protected]=>
string(5) "oops!"
["string":"Exception":private]=>
string(0) ""
["code":protected]=>
int(0)
["file":protected]=>
string(17) "/tmp/toString.php"
["line":protected]=>
int(65)
["trace":"Exception":private]=>
array(1) {
[0]=>
array(6) {
["file"]=>
string(17) "/tmp/toString.php"
["line"]=>
int(71)
["function"]=>
string(10) "__toString"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(0) {
}
}
}
["previous":"Exception":private]=>
NULL
}
Actual result:
--
PHP Fatal error: Method Foo::__toString() must not throw an exception in
/tmp/toString.php on line 0
PHP Stack trace:
PHP 1. {main}() /tmp/toString.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=53648&edit=1
Req #53648 [Com]: Allow __toString() to throw exceptions
Edit report at https://bugs.php.net/bug.php?id=53648&edit=1
ID: 53648
Comment by: benjamin dot morel at strictcoding dot co dot uk
Reported by:clicky at erebot dot net
Summary:Allow __toString() to throw exceptions
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
@nikic: too bad, I did not imagine that this was a problem with PHP internals,
but
rather an architectural choice. Can we keep this feature request open, until
someone finds a solution? It would be good to keep this as a target!
Previous Comments:
[2012-12-04 16:41:50] ni...@php.net
@benjamin: I don't think anyone opposes this feature request, it's just too
hard to implement. Allowing __toString to throw exceptions would require any
internal code doing a zval to string conversion to be exception-safe. See also:
http://markmail.org/message/lkpmpnhrvcbafhkd
[2012-12-04 12:57:36] benjamin dot morel at strictcoding dot co dot uk
I strongly support this feature request.
I haven't read any valid supportive argument so far, for keeping this behaviour
as
it is currently.
In case someone would be worried about backward compatibility issues, this
change
could be introduced with the next major version, PHP 5.5!
I would be grateful if a member of the PHP team could review this request.
[2011-11-10 04:05:48] dqhendricks at hotmail dot com
this problem is causing me such a headache. i'm not even trying to convert an
object
to a string and i'm getting this error. the bug become such a pain to track. i
have
an active record that lazy loads child objects through __get. so even though im
just
trying to print a property of an object that is a string, the fact that a __get
is
used to get that object, prevents me from throwing exceptions. it looks like
this
echo $activerecord->childobject->somestring;
[2011-01-04 14:45:29] clicky at erebot dot net
Description:
Currently, when casting an object with __toString() to a string, __toString()
is not allowed to throw an exception.
Trying to do so triggers an E_ERROR "Method %s::__toString() must not throw an
exception".
IMHO, this is counter-intuitive, especially since calling that object's
__toString() method directly would correctly throw the exception.
I propose to allow __toString() to throw exceptions.
Note: this was already reported in http://bugs.php.net/bug.php?id=50699 but
marked as bogus with the only explanation being "__toString must not throw".
So, I'm marking this as a feature request rather than a bug, since the current
behaviour seems to be expected (though it is not documented in
http://php.net/manual/en/language.oop5.magic.php#language.oop5.magic.tostring).
I also found this entry
http://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring
which cites Johannes saying this requires major changes in the code. However,
the article mentioned is from 2007 and I think the limitations in ZE that
prevented this to be implemented were lifted since then.
I'm not very versed in PHP's inner workings, but attached is a tentative patch
which seems to fix this issue.
Test script:
---
Expected result:
object(CustomException)#2 (7) {
["message":protected]=>
string(5) "oops!"
["string":"Exception":private]=>
string(0) ""
["code":protected]=>
int(0)
["file":protected]=>
string(17) "/tmp/toString.php"
["line":protected]=>
int(65)
["trace":"Exception":private]=>
array(1) {
[0]=>
array(6) {
["file"]=>
string(17) "/tmp/toString.php"
["line"]=>
int(71)
["function"]=>
string(10) "__toString"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(0) {
}
}
}
["previous":"Exception":private]=>
NULL
}
Actual result:
--
PHP Fatal error: Method Foo::__toString() must not throw an exception in
/tmp/toString.php on line 0
PHP Stack trace:
PHP 1. {main}() /tmp/toString.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=53648&edit=1
Bug #18556 [Csd]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1
ID: 18556
Updated by: jpa...@php.net
Reported by:spud at nothingness dot org
Summary:Setting locale to 'tr_TR' lowercases class names
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux (RedHat 7.2)
PHP Version:5CVS, 4CVS (2005-10-04)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
So, to sum things up :
The bugs has only been fixed in 5.5 branch. It mainly uses a char map to lower
characters instead of relying on locale-aware (possibly buggy versions)
system's
libc.
You can find details with internal zend functions affected directly by reading
the source, here : http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#45
Previous Comments:
[2012-09-13 19:19:14] s...@php.net
It looks like snaps is serving 5.4 under the name of php-trunk. Not sure why.
Could you submid a website bug for that and send me the bug ID?
In the meantime you could use github: https://github.com/php/php-src just use
the
"zip file" option and you could build it from there.
[2012-09-13 15:31:04] richlv at nakts dot net
thanks for the response.
$ wget http://snaps.php.net/php-trunk-201209131330.tar.gz
$ wget http://snaps.php.net/php-trunk-201209131330.tar.bz2
$ wget http://snaps.php.net/php-trunk-201209131330.tar.xz
$ for type in gz bz2 xz; do mkdir $type; (cd $type; tar -xf
../php-trunk-201209131330.tar.$type); done
$ grep "PHP_VERSION " {bz2,gz,xz}/php-trunk-201209131330/main/php_version.h
bz2/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"
gz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"
xz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"
is that ok for trunk snapshots then ?
[2012-09-10 06:22:46] s...@php.net
You should be using 5.5 (or master) branch of PHP. It is not fixed in 5.4 due
to necessities of binary APIs change which is not possible in stable version.
Trunk does not announce itself as 5.4 but as 5.5, so there must be some
mistake.
However if you feel very adventurous, you can take 5.5 commit (it's marked with
the bug #) and cherry-pick it into your 5.4 branch.
[2012-09-08 14:54:04] richlv at nakts dot net
hmm, i just tested trunk snapshot php-trunk-201209081330 which announces itself
as 5.4.8-dev
trying to use turkish locale still fails with :
Fatal error: Class 'CInput' not found
(there's uppercase I in the name)
what am i doing wrong ?
[2012-09-08 14:25:15] richlv at nakts dot net
which version is expected to have the fix ? looking at snapshots, is it trunk
only (thus php 5.5 or whichever will be the next version) ?
interesting bit - this bug was fixed just 9 days short of it's 10th birthday ;)
(submitted 2002-07-25, fixed 2012-07-16)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=18556
--
Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
[PHP-BUG] Bug #63688 [NEW]: setlocale() fails on TS build
From: ab Operating system: Windows PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:setlocale() fails on TS build Description: CLI TS build fails to set the locale The relevant place in the code seems to be this: http://lxr.php.net/xref/PHP_5_3/main/SAPI.c#82 Extending this code right in place like _configthreadlocale(_ENABLE_PER_THREAD_LOCALE) setlocale(LC_ALL, "german"); lcnv = localeconv(); lcl = _get_current_locale(); and checking then *lcnv->decimal_point == ',' results in false. As well other values of the lconv scruct don't correspond to the set locale (german in this case). _configthreadlocale()is not invoked in the NTS builds and setlocale works correct there. Test script: --- Those two tests tests\lang\034.phpt tests\lang\bug30638.phpt a simpler test case https://bugs.php.net/bug.php?id=63688&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63688&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63688&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63688&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63688&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63688&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63688&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63688&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63688&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63688&r=support Expected behavior: https://bugs.php.net/fix.php?id=63688&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63688&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63688&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63688&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63688&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63688&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63688&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63688&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63688&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63688&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63688&r=mysqlcfg
Bug #61970 [Com]: Restraining __construct() access level in subclass gives a fatal error
Edit report at https://bugs.php.net/bug.php?id=61970&edit=1
ID: 61970
Comment by: pwolfenden at qualys dot com
Reported by:postmaster at greg0ire dot fr
Summary:Restraining __construct() access level in subclass
gives a fatal error
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.3.12
Block user comment: N
Private report: N
New Comment:
I don't understand why the example described on [2012-05-08 10:46 UTC] by
cataphr...@php.net poses a problem.
I would expect class B to inherit reset(), which remains public. So what?
The point of the factory pattern, for example, is precisely to force the use of
a single method to control the creation of new objects. And it is common OOP
practice to implement this pattern using protected constructor methods. So it
strikes me as bizzarre that PHP forces me to modify the whole class hierarchy
if
I want to enforce the use of a factory method for a derived class, and the base
class has a public constructor.
Thank you, greg0ire, for opening this bug.
Previous Comments:
[2012-05-08 13:04:18] postmaster at greg0ire dot fr
Thanks for the detailed answer, it is very informative, especially the first
bit, which even shows the LSP could be applied in this case.
[2012-05-08 10:46:42] cataphr...@php.net
It's true that PHP's behavior doesn't make a lot of sense from a theoretical
perspective. However, there are some practical reasons why a different behavior
would be -- arguably -- less desirable.
Namely, in PHP the constructor can be called from every instance method, even
after construction. This makes it a necessity that the constructor act like
regular instance methods. Consider:
a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}
Plus, PHP allows enforcing constructor signatures via interfaces. This means
you have to enforce that signature throughout the hierarchy, and this includes
not allows changing the visibility of the constructor.
Similarly, there's no principled reason to be unable to reduce the visibility
in static methods. But PHP also prohibits such a pattern, like Java does, even
though there's no overriding (the method in the superclass is said to be
hidden). But PHP, like Java, allows calling static methods through an instance
and through the subclass name. Then if you call the reduced visibility static
method with the subclass name or a subclass instance, what would you do? Would
it depend on the access of the caller has to the subclass method?
[2012-05-07 18:47:00] postmaster at greg0ire dot fr
fixed the title
[2012-05-07 18:40:56] postmaster at greg0ire dot fr
Description:
Restraining the __construct() method un a subtype gives a Fatal error.
As stated in the following resources, the LSP should not apply here.
- https://bugs.php.net/bug.php?id=40880
-
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
-
http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern
Test script:
---
PHP Fatal error: Access level to Bar::__construct() must be public (as in
> class Foo) in /tmp/bug.php on line 9
> Fatal error: Access level to Bar::__construct() must be public (as in class
> Foo) in /tmp/bug.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=61970&edit=1
Bug #63686 [Asn->Csd]: Build with --enable-dtrace fails
Edit report at https://bugs.php.net/bug.php?id=63686&edit=1 ID: 63686 Updated by: d...@php.net Reported by:d...@php.net Summary:Build with --enable-dtrace fails -Status: Assigned +Status: Closed Type: Bug Package:*General Issues Operating System: Solaris PHP Version:5.5Git-2012-12-04 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-04 14:34:28] d...@php.net Description: building with --enable-dtrace results in Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) which was introduced in commit 70f83f35d089d0cafae12ae231a38541f5c8e41c Author: Dmitry Stogov Date: Fri Nov 30 13:39:23 2012 +0400 Test script: --- ./buildconf ./configure --enable-dtrace make Expected result: build complete Actual result: -- /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_get_executed_filenameâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function âdtrace_executeâ: /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing argument 1 of âget_active_class_nameâ from incompatible pointer type [enabled by default] In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0, from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22: /home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected âconst char **â but argument is of type âchar **â /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment discards âconstâ qualifier from pointer target type [enabled by default] /home/dsp/dev/php/src/5.5/Zend/zend.c: In function âzend_startupâ: /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error: âdtrace_execute_exâ undeclared (first use in this function) /home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared identifier is reported only once for each function it appears in make: *** [Zend/zend.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit this bug report at https://bugs.php.net/bug.php?id=63686&edit=1
Req #49188 [Com]: DateTime::__construct should allow a DateTime-object to be passed as argument
Edit report at https://bugs.php.net/bug.php?id=49188&edit=1
ID: 49188
Comment by: will dot sskates at ntlworld dot com
Reported by:niklas at narhinen dot net
Summary:DateTime::__construct should allow a DateTime-object
to be passed as argument
Status: Open
Type: Feature/Change Request
Package:Date/time related
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
You can pass the time string instead. What is the use case for this?
Previous Comments:
[2009-08-07 08:18:54] niklas at narhinen dot net
Description:
DateTime::__construct should allow a DateTime object to be passed as parameter
to emulate good object desing (Copy constructor).
This wouldn't break anything.
Reproduce code:
---
myDateTime = new
DateTime($datetime); }
public function getTime($format = "Y-m-d") { return
$this->myDateTime->format($format); }
}
$class = new MyClass();
$class->setTime("7.8.2009");
var_dump($class->getTime());
$class->setTime(null);
var_dump($class->getTime());
$dt = new DateTime('15.5.2005');
$class->setTime($dt);
var_dump($class->getTime());
?>
Expected result:
string(10) "2009-08-07"
string(10) "2009-08-07"
string(10) "2005-05-15"
Actual result:
--
string(10) "2009-08-07"
string(10) "2009-08-07"
PHP Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() expects parameter 1 to be string, object gi
ven' in D:\temp\php\datetime.php:7
Stack trace:
#0 D:\temp\php\datetime.php(7): DateTime->__construct(Object(DateTime))
#1 D:\temp\php\datetime.php(17): MyClass->setTime(Object(DateTime))
#2 {main}
thrown in D:\temp\php\datetime.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=49188&edit=1
Bug #60706 [Com]: Unable to compile pdo_mysql with mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60706&edit=1 ID: 60706 Comment by: ronald dot bradford at gmail dot com Reported by:martin at martins-creations dot co dot uk Summary:Unable to compile pdo_mysql with mysqlnd Status: Feedback Type: Bug Package:PDO related Operating System: Debian PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: I experience the same problem running $ pecl install mysqlnd_ms Both the 5.3.19 and 5.4.6 sources I can obtain mysqlnd.h and mysqlnd_portability.h but there is no such php_mysqlnd_config.h Previous Comments: [2012-10-17 01:27:27] siefkesilvio at gmail dot com Hello, on my System i become the same msg. I compiled mysqlnd as Plugin and it ends with the same msg. cc -I. -I/usr/local/src/php-5.4.7/ext/mysqlnd -DPHP_ATOM_INC -I/usr/local/src/php-5.4.7/ext/mysqlnd/include -I/usr/local/src/php-5.4.7/ext/mysqlnd/main -I/usr/local/src/php-5.4.7/ext/mysqlnd -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /usr/local/src/php-5.4.7/ext/mysqlnd/mysqlnd.c -fPIC -DPIC -o .libs/mysqlnd.o In file included from /usr/local/src/php-5.4.7/ext/mysqlnd/mysqlnd.h:60, from /usr/local/src/php-5.4.7/ext/mysqlnd/mysqlnd.c:23: /usr/local/src/php-5.4.7/ext/mysqlnd/mysqlnd_portability.h:40:46: error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory make: *** [mysqlnd.lo] Error 1 :/usr/local/src/php-5.4.7/ext/mysqlnd# ls | grep php php_mysqlnd.c php_mysqlnd.h run-tests.php php -v PHP 5.4.7 (cli) (built: Oct 16 2012 23:23:27) phpize -v Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 [2012-01-24 16:21:31] ras...@php.net Unable to reproduce. On my dev box I use: --with-pdo-mysql=mysqlnd --with-mysqli=mysqlnd and it has always built cleanly. [2012-01-10 23:48:00] martin at martins-creations dot co dot uk Description: Initially I was getting: /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27:34: fatal error: ext/mysqlnd/mysqlnd.h: No such file or directory so I did a mkdir ext && cp -r ../mysqlnd ./ext to fix the path issue. # php -v PHP 5.4.0RC4 (cli) (built: Jan 3 2012 12:00:03) # phpize -v Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 Test script: --- phpize && ./configure && make && make install Expected result: Successful compilation Actual result: -- In file included from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd.h:60:0, from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27, from /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/pdo_mysql.c:32: /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd_portability.h:40:46: fatal error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory sure enough: total 804 drwxr-xr-x 2 root root 4096 Jan 10 18:27 . drwxr-xr-x 3 root root 4096 Jan 10 18:33 .. -rw-r--r-- 1 root root 2230 Jan 10 18:27 config9.m4 -rw-r--r-- 1 root root 1172 Jan 10 18:27 config.w32 -rw-r--r-- 1 root root 3312 Jan 10 18:27 config-win.h -rw-r--r-- 1 root root50 Jan 10 18:27 CREDITS -rw-r--r-- 1 root root 20160 Jan 10 18:27 mysqlnd_alloc.c -rw-r--r-- 1 root root 5934 Jan 10 18:27 mysqlnd_alloc.h -rw-r--r-- 1 root root 16643 Jan 10 18:27 mysqlnd_auth.c -rw-r--r-- 1 root root 5955 Jan 10 18:27 mysqlnd_block_alloc.c -rw-r--r-- 1 root root 1750 Jan 10 18:27 mysqlnd_block_alloc.h -rw-r--r-- 1 root root 14026 Jan 10 18:27 mysqlnd_bt.c -rw-r--r-- 1 root root 85349 Jan 10 18:27 mysqlnd.c -rw-r--r-- 1 root root 28599 Jan 10 18:27 mysqlnd_charset.c -rw-r--r-- 1 root root 2450 Jan 10 18:27 mysqlnd_charset.h -rw-r--r-- 1 root root 24722 Jan 10 18:27 mysqlnd_debug.c -rw-r--r-- 1 root root 7552 Jan 10 18:27 mysqlnd_debug.h -rw-r--r-- 1 root root 9753 Jan 10 18:27 mysqlnd_driver.c -rw-r--r-- 1 root root 17588 Jan 10 18:27 mysqlnd_enum_n_def.h -rw-r--r-- 1 root root 6530 Jan 10 18:27 mysqlnd_ext_plugin.c -rw-r--r-- 1 root root 3941 Jan 10 18:27 mysqlnd_ext_plugin.h -rw-r--r-- 1 root root 17025 Jan 10 18:27 mysqlnd.h -rw-r--r-- 1 root root 7534 Jan 10 18:27 mysqlnd_libmysql_compat.h -rw-r--r-- 1 root root 7651 Jan 10 18:27 mysqlnd_loaddata.c -rw-r--r-- 1 root root 36242 Jan 10 18:27 mysqlnd_net.c -rw-r--r-- 1 root root 1812 Jan 10 18:27 mysqlnd_net.h -rw-r--r-- 1 root root 5660 Jan 10 18:27 mysqlnd_plugin.c -rw-r--r-
Bug #61970 [Opn]: Restraining __construct() access level in subclass gives a fatal error
Edit report at https://bugs.php.net/bug.php?id=61970&edit=1
ID: 61970
User updated by:postmaster at greg0ire dot fr
Reported by:postmaster at greg0ire dot fr
Summary:Restraining __construct() access level in subclass
gives a fatal error
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.3.12
Block user comment: N
Private report: N
New Comment:
Perhaps I understood it one day, but now, I just can't recall why this example
could be a problem.
@cataphract: maybe you could elaborate? I think the expected behavior would be
the private constructor to be called when calling B::reset() ... To answer your
questions, I would definitely take the caller access into account when calling
the static methods.
Previous Comments:
[2012-12-04 19:10:32] pwolfenden at qualys dot com
I don't understand why the example described on [2012-05-08 10:46 UTC] by
cataphr...@php.net poses a problem.
I would expect class B to inherit reset(), which remains public. So what?
The point of the factory pattern, for example, is precisely to force the use of
a single method to control the creation of new objects. And it is common OOP
practice to implement this pattern using protected constructor methods. So it
strikes me as bizzarre that PHP forces me to modify the whole class hierarchy
if
I want to enforce the use of a factory method for a derived class, and the base
class has a public constructor.
Thank you, greg0ire, for opening this bug.
[2012-05-08 13:04:18] postmaster at greg0ire dot fr
Thanks for the detailed answer, it is very informative, especially the first
bit, which even shows the LSP could be applied in this case.
[2012-05-08 10:46:42] cataphr...@php.net
It's true that PHP's behavior doesn't make a lot of sense from a theoretical
perspective. However, there are some practical reasons why a different behavior
would be -- arguably -- less desirable.
Namely, in PHP the constructor can be called from every instance method, even
after construction. This makes it a necessity that the constructor act like
regular instance methods. Consider:
a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}
Plus, PHP allows enforcing constructor signatures via interfaces. This means
you have to enforce that signature throughout the hierarchy, and this includes
not allows changing the visibility of the constructor.
Similarly, there's no principled reason to be unable to reduce the visibility
in static methods. But PHP also prohibits such a pattern, like Java does, even
though there's no overriding (the method in the superclass is said to be
hidden). But PHP, like Java, allows calling static methods through an instance
and through the subclass name. Then if you call the reduced visibility static
method with the subclass name or a subclass instance, what would you do? Would
it depend on the access of the caller has to the subclass method?
[2012-05-07 18:47:00] postmaster at greg0ire dot fr
fixed the title
[2012-05-07 18:40:56] postmaster at greg0ire dot fr
Description:
Restraining the __construct() method un a subtype gives a Fatal error.
As stated in the following resources, the LSP should not apply here.
- https://bugs.php.net/bug.php?id=40880
-
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
-
http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern
Test script:
---
PHP Fatal error: Access level to Bar::__construct() must be public (as in
> class Foo) in /tmp/bug.php on line 9
> Fatal error: Access level to Bar::__construct() must be public (as in class
> Foo) in /tmp/bug.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=61970&edit=1
Req #53648 [Opn->Sus]: Allow __toString() to throw exceptions
Edit report at https://bugs.php.net/bug.php?id=53648&edit=1
ID: 53648
Updated by: ahar...@php.net
Reported by:clicky at erebot dot net
Summary:Allow __toString() to throw exceptions
-Status: Open
+Status: Suspended
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Suspending: as Stas explained in the linked e-mail thread, it's "pretty hard"
to do in the current engine.
Should there ever be a Zend Engine 3, however, this could be revisited.
Previous Comments:
[2012-12-04 17:15:19] benjamin dot morel at strictcoding dot co dot uk
@nikic: too bad, I did not imagine that this was a problem with PHP internals,
but
rather an architectural choice. Can we keep this feature request open, until
someone finds a solution? It would be good to keep this as a target!
[2012-12-04 16:41:50] ni...@php.net
@benjamin: I don't think anyone opposes this feature request, it's just too
hard to implement. Allowing __toString to throw exceptions would require any
internal code doing a zval to string conversion to be exception-safe. See also:
http://markmail.org/message/lkpmpnhrvcbafhkd
[2012-12-04 12:57:36] benjamin dot morel at strictcoding dot co dot uk
I strongly support this feature request.
I haven't read any valid supportive argument so far, for keeping this behaviour
as
it is currently.
In case someone would be worried about backward compatibility issues, this
change
could be introduced with the next major version, PHP 5.5!
I would be grateful if a member of the PHP team could review this request.
[2011-11-10 04:05:48] dqhendricks at hotmail dot com
this problem is causing me such a headache. i'm not even trying to convert an
object
to a string and i'm getting this error. the bug become such a pain to track. i
have
an active record that lazy loads child objects through __get. so even though im
just
trying to print a property of an object that is a string, the fact that a __get
is
used to get that object, prevents me from throwing exceptions. it looks like
this
echo $activerecord->childobject->somestring;
[2011-01-04 14:45:29] clicky at erebot dot net
Description:
Currently, when casting an object with __toString() to a string, __toString()
is not allowed to throw an exception.
Trying to do so triggers an E_ERROR "Method %s::__toString() must not throw an
exception".
IMHO, this is counter-intuitive, especially since calling that object's
__toString() method directly would correctly throw the exception.
I propose to allow __toString() to throw exceptions.
Note: this was already reported in http://bugs.php.net/bug.php?id=50699 but
marked as bogus with the only explanation being "__toString must not throw".
So, I'm marking this as a feature request rather than a bug, since the current
behaviour seems to be expected (though it is not documented in
http://php.net/manual/en/language.oop5.magic.php#language.oop5.magic.tostring).
I also found this entry
http://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring
which cites Johannes saying this requires major changes in the code. However,
the article mentioned is from 2007 and I think the limitations in ZE that
prevented this to be implemented were lifted since then.
I'm not very versed in PHP's inner workings, but attached is a tentative patch
which seems to fix this issue.
Test script:
---
Expected result:
object(CustomException)#2 (7) {
["message":protected]=>
string(5) "oops!"
["string":"Exception":private]=>
string(0) ""
["code":protected]=>
int(0)
["file":protected]=>
string(17) "/tmp/toString.php"
["line":protected]=>
int(65)
["trace":"Exception":private]=>
array(1) {
[0]=>
array(6) {
["file"]=>
string(17) "/tmp/toString.php"
["line"]=>
int(71)
["function"]=>
string(10) "__toString"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(0) {
}
}
}
["previous":"Exception":private]=>
NULL
}
Actual result:
--
PHP Fatal error: Method Foo::__toString() must not throw an exception in
/tmp/toString.php on line 0
PHP Stack trace:
PHP 1. {main}() /tmp/toString.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=53648&edit=1
Bug #50699 [Nab]: Cannot throw Exceptions in __toString()
Edit report at https://bugs.php.net/bug.php?id=50699&edit=1 ID: 50699 Updated by: ahar...@php.net Reported by:gmblar+php at gmail dot com Summary:Cannot throw Exceptions in __toString() Status: Not a bug Type: Bug Package:*General Issues Operating System: * PHP Version:5.3.1 Block user comment: N Private report: N New Comment: I have updated the manual to note the issue, so consider it documented. :) Previous Comments: [2012-12-05 01:18:52] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=328669 Log: Add a warning about the fatal error generated when you throw from __toString(). Prompted by bug #50699, although it doesn't really fix it as such. [2012-12-04 13:05:14] benjamin dot morel at strictcoding dot co dot uk @bjori The documentation does not say that __toString() must not throw an exception. The fact is, this is currently an undocumented behaviour, that could therefore be changed without causing much pain (we're supposed to write code based on the documented behaviour of a function, not its side effects): http://php.net/manual/en/language.oop5.magic.php#object.tostring A feature request has been open, I would be grateful if you could give your opinion there, especially now than PHP 5.5 is being developed: https://bugs.php.net/bug.php?id=53648 Thank you. [2010-01-08 22:51:46] gmblar+php at gmail dot com Current behavior of __toString is crap. Why i can use trigger_error() bug not throw Exception() in __toString()? Please fix it. [2010-01-08 22:24:09] bj...@php.net 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 __toString() must not throw exceptions [2010-01-08 22:22:35] gmblar+php at gmail dot com Description: Cannot throw Exceptions in __toString(). Instead it produces a Fatal error. Reproduce code: --- Expected result: Fatal error: Uncaught exception 'Exception' with message 'Incomplete Data' in /-:6 Actual result: -- Fatal error: Method bar::__toString() must not throw an exception in /- on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=50699&edit=1
Bug #44639 [Com]: PDO quotes integers in prepared statement
Edit report at https://bugs.php.net/bug.php?id=44639&edit=1
ID: 44639
Comment by: alek0585 at mail dot ru
Reported by:jgauld at blueyonder dot co dot uk
Summary:PDO quotes integers in prepared statement
Status: Open
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
Yeah! Try this $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); and you
can
use that!
foreach($data as $key => $value) {
$stmt->bindParam( ":".$key, $value, (is_int($value) ?
PDO::PARAM_INT :
PDO::PARAM_STR));
}
but you should be careful with types of vars
Previous Comments:
[2012-03-12 10:15:44] alvaro at demogracia dot com
This only happens on emulated parameter binding, i.e. when
PDO::ATTR_EMULATE_PREPARES is TRUE.
[2012-02-25 06:28:34] preludeinz at gmail dot com
Please fix! I can't do my course's lab exercise (without introducing a SQL
injection vulnerability) without this feature.
[2012-01-13 19:50:40] engin at e-php dot net
It's really sad seeing this aged bug is not gonna fixed.
[2011-12-13 22:33:36] stephen-d at rogers dot com
I am surprised that something this simple has been unfixed for so long.
I wasted 8 hours trying to figure out "my" mistake. Thinking that it was a PDO
bug was inconceivable.
I finally turned on MySQL logging and saw that the numeric argument was being
enclosed in quotes. I posted to a web site for help and a kind person sent me
this link.
For others struggling with this, the work-around is to type caste all numeric
values that will passed to PBO.
[2011-04-27 20:24:08] riksoft at gmail dot com
Php-cli V. 5.3.1:
I see that if no PDO::PARAM_* is used PDO use variable type.
E.g.
$sth->bindValue(6, $checksum, PDO::PARAM_INT);
or
$sth->bindValue(6, $checksum);
correctly treat the value $checksum (CRC32 int) as a number
BUT
there is a problem with unsigned integer: according to
http://it.php.net/manual/en/pdo.constants.php
there isn't any useful costant for larger numeric value.
Real case: The only way to store a crc32 value among different DBs and
platforms (32/64 bit) is converting CRC32 to unsigned int this way
sprintf("%u",crc32). But PDO::PARAM_INT is not able to handle values larger
than 2147483647.
Solution: security of inputs by floatval() (at least when bindvalue dont write
as a string which is not my case).
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=44639
--
Edit this bug report at https://bugs.php.net/bug.php?id=44639&edit=1
Bug #63666 [Opn->Csd]: Poor date() performance [PATCH]
Edit report at https://bugs.php.net/bug.php?id=63666&edit=1
ID: 63666
Updated by: s...@php.net
Reported by:njaguar at gmail dot com
Summary:Poor date() performance [PATCH]
-Status: Open
+Status: Closed
Type: Bug
Package:Performance problem
Operating System: any
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of stas
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=fd650ec93e15bbbc05542e4acdde13d1fd9bcf73
Log: fix bug #63666 - Poor date() performance
Previous Comments:
[2012-12-02 00:50:20] njaguar at gmail dot com
Description:
Full info here:
http://news.php.net/php.internals/64127
4.4.9 on old machine vs 5.4.9 on new machine:
date: 1.856 sec date: 2.111 sec
after patch (~20% performance increase):
date: 1.763 sec
* new machine is 2 to 200x faster than old machine, see link above for more
details
Test script:
---
// common date output format
// use any preferred timing methods either within php, or externally time
execution of the script (eg, microtime(), etc) -- the former will be more
accurate at isolating the date() function, overall
$c = 100;
for($i=0; $i<$c; $i++) date('F j, Y, g:i a', $now);
Expected result:
worse performance on stock builds, better when patch is applied -- still
considerably slower than 4.4.9 version of date() and related, but is an
improvement
Actual result:
--
By moving the frequently used iso fetching function into the switch statement,
this prevents an otherwise unnecessary step for other more common usages of
date formatting.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63666&edit=1
Bug #60034 [Com]: Build fails with apxs and readline
Edit report at https://bugs.php.net/bug.php?id=60034&edit=1 ID: 60034 Comment by: boboudreau at gmail dot com Reported by:notfornoone at gmail dot com Summary:Build fails with apxs and readline Status: Open Type: Bug Package:Compile Failure Operating System: OS X (i386-apple-darwin10.8.0) PHP Version:5.4SVN-2011-10-10 (snap) Block user comment: N Private report: N New Comment: I had a similar problem, and this bug came up in my Google search results. To help anyone else with the solution, I'll post the problem and solution here. Here's what my build output contained when trying to add '--with-readline': Undefined symbols: "_rl_completion_matches", referenced from: __readline_completion_cb in readline.o _cli_code_completion in readline_cli.o "_rl_mark", referenced from: _rl_mark$non_lazy_ptr in readline.o "_rl_on_new_line", referenced from: _zif_readline_on_new_line in readline.o "_rl_pending_input", referenced from: _rl_pending_input$non_lazy_ptr in readline.o "_history_list", referenced from: _zif_readline_list_history in readline.o ld: symbol(s) not found collect2: ld returned 1 exit status >From what I can tell, the problem building --with-readline on a Mac is that libreadline.dylib in /usr/lib is not technically the readline library. It's a symlink to libedit.dylib in the same directory. So I managed to install another, actual readline library using fink (you could compile it yourself), and temporarily changed the symlink in /usr/lib: me:/usr/lib # unlink libreadline.dylib me:/usr/lib # ln -s /path/to/my/other/libreadlinelib.dylib libreadline.dylib once that's done, it builds and links. you can put back the old symlink once you're done: me:/usr/lib # unlink libreadline.dylib me:/usr/lib # ln -s libedit.dylib libreadline.dylib Previous Comments: [2012-11-22 07:50:17] phpnet at jigsoft dot co dot za from nickl: I can't take all the credit, thanks goes to Areverie who discovered the solution and documented it on his blog http://weblog.areverie.org/blog/2012/03/18/fun-stuff-about-php/ in March of 2012 What he found was that if we move the variable $(MH_BUNDLE_FLAGS) to the end of the list of compiler flags the build will succeed. The submitted patch modifies Makefile.global, the origin of the bug produced after running the ./configure script. This now successfully completes make and the resulting php binary reports the desired extension correctly, as expected. readline Readline Support => enabled Readline library => 6.2 patch and testing done against PHP 5.4.8 on Mac OS X 10.8.2 nJoy! [2011-10-10 22:41:18] notfornoone at gmail dot com Description: When compiling on 10.6 with the following configure args the build fails: ./configure '--prefix=/Users/me/Desktop/php54test' '--disable-all' '--with- apxs2=/usr/sbin/apxs' '--with-readline=/usr/local/Cellar/readline/6.2.1' make Fails with this error: Undefined symbols for architecture x86_64: "_rl_on_new_line", referenced from: _zif_readline_on_new_line in readline.o "_history_list", referenced from: _zif_readline_list_history in readline.o "_rl_mark", referenced from: _zif_readline_info in readline.o "_rl_pending_input", referenced from: _zif_readline_info in readline.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 I've also tried: * Using an earler version of readline (6.1) fails with the same error * Compiling on 10.7 Lion results in the same error * Using the same configure options using the 5.3 branch builds fine * Compiling with configure options "--with-libedit" enabled instead of the "-- with-readline" option builds fine -- Edit this bug report at https://bugs.php.net/bug.php?id=60034&edit=1
[PHP-BUG] Bug #63690 [NEW]: Problems with a manual transaction while auto commit is enabled.
From: james at kenjim dot com Operating system: All PHP version: master-Git-2012-12-05 (Git) Package: PDO related Bug Type: Bug Bug description:Problems with a manual transaction while auto commit is enabled. Description: The documentation at http://php.net/manual/en/pdo.transactions.php gives me the impression that the default mode a pdo db driver is in is auto-commit. If I choose to create a batch of queries in one transaction I can do so by first issuing a begin transaction. This however does not appear to be the case when looking at the c code for all but the odbc pdo driver. Auto-commit is never actually disabled so all my queries in my transaction block get committed when they get executed. I have only tested this behavior with Firebird. I have created a patch that will turn off auto-commit at the driver level when beginTransaction is called and will restore the user setting when commit or rollback is called. This way all pdo drivers that support transactions and auto-commit should now act properly. The patch also includes the ability to support commits/rollbacks that keep the transaction open. Also included in this patch is my patch from Request #63215 since I realized that patch needed pdo to support the ability to keep a transaction open after calling commit/rollback. Please note my patch was only tested with the Firebird database driver so other database drivers should have their beginTransaction with auto-commit on functionality tested. -- Edit bug report at https://bugs.php.net/bug.php?id=63690&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63690&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63690&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63690&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63690&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63690&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63690&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63690&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63690&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63690&r=support Expected behavior: https://bugs.php.net/fix.php?id=63690&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63690&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63690&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63690&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63690&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63690&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63690&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63690&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63690&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63690&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63690&r=mysqlcfg
[PHP-BUG] Bug #63691 [NEW]: Segmentation Fault (_zend_mm_free_int)
From: shivammaharshi at gmail dot com Operating system: i386-redhat-linux PHP version: 5.4.9 Package: *General Issues Bug Type: Bug Bug description:Segmentation Fault (_zend_mm_free_int) Description: I am getting segmentation faults on the live server. Here is the core dump below. PHP Version : 5.4.6 Zend Module is Used. Please Notice that segmentation faults are 50-100 a day in number. The total hits I am getting on my Live servers are > 1. So no script can be given to reproduce this error. From what I understand this has a problem with accessing the variable which has been de-referenced already. Thus getting segmentation faults. Kindly help me fix this, or may be suggest a work around. Core was generated by `/usr/local/apache/bin/httpd -k start'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libssl.so.4...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/local/apache/lib/libaprutil-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /usr/lib/tls/i686/libdb-4.2.so...done. Loaded symbols for /usr/lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/apache/lib/libapr-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/apache/modules/libphp5.so...done. Loaded symbols for /usr/local/apache/modules/libphp5.so Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.15...done. Loaded symbols for /usr/local/mysql/lib/mysql/libmysqlclient.so.15 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libcurl.so.3...done. Loaded symbols for /usr/lib/libcurl.so.3 Reading symbols from /usr/lib/libidn.so.11...done. Loaded symbols for /usr/lib/libidn.so.11 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/local/apache/modules/mod_expires.so...done. Loaded symbols for /usr/local/apache/modules/mod_expires.so Reading symbols from /usr/local/apache/modules/mod_headers.so...done. Loaded symbols for /usr/local/apache/modules/mod_headers.so Reading symbols from /usr/local/apache/modules/mod_rpaf-2.0.so...done. Loaded symbols for /usr/local/apache/modules/mod_rpaf-2.0.so Reading symbols from /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/xcache.so...done. Loaded symbols for /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/xcache.so Reading symbols from /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/pdo.so...done. Loaded symbols for /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/pdo.so Reading symbols from /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/pdo_mysql.so...done. Loaded symbols for /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/pdo_mysql.so Reading symbols from /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/memcache.so...done. Loaded symbols for /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/memcache.so Reading symbols from /usr/local/php/lib/php/extensions/no-debug-non-zts- 20060613/wordmapping.so...done. Loaded symbols for /usr/local/php/lib/php/extensions/no-debug-non-zts- 2
Req #63215 [Com]: Add support for Firebird commit retaining transactions.
Edit report at https://bugs.php.net/bug.php?id=63215&edit=1 ID: 63215 Comment by: james at kenjim dot com Reported by:james at kenjim dot com Summary:Add support for Firebird commit retaining transactions. Status: Assigned Type: Feature/Change Request Package:PDO related Operating System: All PHP Version:5.4Git-2012-10-03 (Git) Assigned To:mariuz Block user comment: N Private report: N New Comment: I have uploaded a new improved patch with Bug #63690 that includes the functionality here. I suggest using that patch instead of the one I uploaded here as that is a more complete solution and fixes some unexpected behavior if someone uses commit retaining. Previous Comments: [2012-10-04 00:01:51] james at kenjim dot com Description: Add the ability to do commit retaining transactions using the Firebird PDO driver. Commit retaining is faster when committing because it reuses server transaction resources. The downside is you are still in the old transaction context so you won't see any new concurrent commits. Commit retaining is ideally used when you have lots of small transactions that do not rely on other data that may be changed by another thread/user. I have written a patch to add the ability to do commit retaining transactions using $dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, true); Any following commits or rollbacks will use their retaining equivalent after this attribute is set. You can return to using normal commit and rollbacks by setting the attribute to false. $dbh->setAttribute(PDO::FB_ATTR_COMMIT_RETAINING, false); -- Edit this bug report at https://bugs.php.net/bug.php?id=63215&edit=1
[PHP-BUG] Req #63693 [NEW]: Create objects with array of parameters
From: rayro at gmx dot de Operating system: Any PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Create objects with array of parameters Description: Currently it is (not possible) to create an object using an array of parameters. You have to type in each parameter for the constructor manually... (see script #1) As it is possible to call functions using call_user_func_array, it would also be nice to create objects like that. The only trick to make this possible is to make the use of Reflection. (see script #2) The paranthesis indicate that the arguments for __construct will be passed. The idea is to omit the paranthesis and pass the arguments as array. (see script #3) But this is only my idea... Maybe the best way is to provide a function for that, like call_user_func_array() for functions exists... (see script #4) Additionally another idea is to change the way "new" works, enabling to pass parameters to new. (see script #5) But for me, #3 is the best solution, because IF it would be possible in future releases of php to cast to an object, the new keyword can simply be omitted while making the use of paranthesis. (see script #6) thx for listenig :) Test script: --- #1 #2 newInstanceArgs($array); ?> #3 #4 #5 #6 Expected result: A function or language construct to provide making objects of classes quickly. Actual result: -- No way instead of making the use of Reflection... -- Edit bug report at https://bugs.php.net/bug.php?id=63693&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63693&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63693&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63693&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63693&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63693&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63693&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63693&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63693&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63693&r=support Expected behavior: https://bugs.php.net/fix.php?id=63693&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63693&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63693&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63693&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63693&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63693&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63693&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63693&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63693&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63693&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63693&r=mysqlcfg
