Bug #60955 [Com]: spl_autoload_register() accept a protected method
Edit report at https://bugs.php.net/bug.php?id=60955edit=1
ID: 60955
Comment by: php-dev at zerocue dot com
Reported by:frederic dot hardy at mageekbox dot net
Summary:spl_autoload_register() accept a protected method
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
This report is requesting a change in the error output? It already doesn't
allow
the protected member to be registered as your actual result indicates, it
throws
an error.
What is this report about?
Previous Comments:
[2012-02-02 14:02:59] frederic dot hardy at mageekbox dot net
Description:
It's possible to register a protected method as an autoloader callback with the
function spl_autoload_register().
Test script:
---
?php
class autoloader
{
function register()
{
spl_autoload_register(array($this, 'requireClass'));
}
protected function requireClass() {}
}
$autoloader = new autoloader();
$autoloader-register();
$autoloadFunctions = spl_autoload_functions();
foreach ($autoloadFunctions as $autoloadFunction)
{
spl_autoload_unregister($autoloadFunction);
}
foreach ($autoloadFunctions as $autoloadFunction)
{
spl_autoload_register($autoloadFunction);
}
Expected result:
Cannot register the protected method autoload::requireClass() as a callback
Actual result:
--
Passed array does not specify a callable method (cannot access protected method
autoloader::requireClass())
--
Edit this bug report at https://bugs.php.net/bug.php?id=60955edit=1
Bug #60977 [Com]: number_format behavior changed when passing \0 for 4th parameter.
Edit report at https://bugs.php.net/bug.php?id=60977edit=1 ID: 60977 Comment by: php-dev at zerocue dot com Reported by:chobie...@php.net Summary:number_format behavior changed when passing \0 for 4th parameter. Status: Open Type: Bug Package:Math related Operating System: OSX PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: This is interesting, I would think that the 5_4 functionality is more correct, because you're adding a null character as the thousands separator so the string is becoming: 1\0328\0370\0011.7238 Internally a null character terminates a C style string. I would think the appropriate fix would be to limit the fourth parameter to displayable characters. This probably changed as a result of a bugfix somewhere. Previous Comments: [2012-02-04 15:58:09] chobie...@php.net Description: when I run the test code on php5.3. php returns `1328370011.7238`. but in php5.4 that returns `1`. i don't know which behavior is correct. i think it should be returns same result. Test script: --- ?php echo number_format(1328370011.724,8,., \0); Expected result: 1328370011.7238 Actual result: -- 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60977edit=1
Req #60957 [Com]: if function returns false on error, don't emit a warning
Edit report at https://bugs.php.net/bug.php?id=60957edit=1
ID: 60957
Comment by: php-dev at zerocue dot com
Reported by:joel at purerave dot com
Summary:if function returns false on error, don't emit a
warning
Status: Open
Type: Feature/Change Request
Package:Filesystem function related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
On my box with 54RC7, executing filemtime on a file that doesn't exist
executing
10,000 times takes 6.5 seconds, using the @ to suppress the error takes 0.058
seconds so suppression with @ is pretty fast. I'd say this is bogus.
If you're still logging the error with an @ because you have a custom error
logger
you can detect the use of the @ from within the error catch function.
Previous Comments:
[2012-02-02 16:58:24] joel at purerave dot com
Description:
functions that return FALSE on error should not also emit a warning.
Example: filemtime(). it is sufficient to check if the file exists and retrieve
the mtime by doing:
if ($mtime = filemtime()) {
echo date('ymd', $mtime);
} else {
echo 'file does not exist';
}
supressing the warning with @ is slow and generates an error in the log (also
slow). checking if the file exists before retrieving the mtime is also wasteful.
Expected result:
filemtime and other functions that emit a warning on error when false is also
returned should not emit a warning.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60957edit=1
Bug #60940 [Com]: SplFileInfo::getLinkTarget fails
Edit report at https://bugs.php.net/bug.php?id=60940edit=1
ID: 60940
Comment by: php-dev at zerocue dot com
Reported by:aheadley at nexcess dot net
Summary:SplFileInfo::getLinkTarget fails
Status: Open
Type: Bug
Package:SPL related
Operating System: Fedora 16
PHP Version:5.3SVN-2012-01-31 (snap)
Block user comment: N
Private report: N
New Comment:
Confirmed works in 5.4RC7 and trunk as well.
Previous Comments:
[2012-01-31 21:57:58] aheadley at nexcess dot net
It also appears to be working in 5.4.0RC6.
[2012-01-31 21:38:42] aheadley at nexcess dot net
Description:
SplFileInfo::getLinkTarget
(http://www.php.net/manual/en/splfileinfo.getlinktarget.php) does not seem to
work at all. It fails with a Unable to read link symlink name, error:
Invalid argument message. Reproduced on 5.3.8 and 5.3.10-dev snapshot
(201201312030) but works on 5.2.17.
This similar but not quite the same as #51804
(https://bugs.php.net/bug.php?id=51804)
Test script:
---
touch('testfile');
symlink('testfile', 'testlink');
$f = new SplFileInfo( 'testlink' );
printf( 'readlink: %s'.PHP_EOL, readlink( $f-getPathname() ) );
printf( 'SplFileInfo::getLinkTarget: %s'.PHP_EOL, $f-getLinkTarget() );
Expected result:
readlink: testfile
SplFileInfo::getLinkTarget: testfile
Actual result:
--
readlink: testfile
Fatal error: Uncaught exception 'RuntimeException' with message 'Unable to read
link testlink, error: Invalid argument' in
/home/aheadley/Desktop/testing/test.php:6
Stack trace:
#0 /home/aheadley/Desktop/testing/test.php(6): SplFileInfo-getLinkTarget()
#1 {main}
thrown in /home/aheadley/Desktop/testing/test.php on line 6
--
Edit this bug report at https://bugs.php.net/bug.php?id=60940edit=1
Bug #60978 [Com]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978edit=1 ID: 60978 Comment by: php-dev at zerocue dot com Reported by:the...@php.net Summary:exit code incorrect Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: Looks like this (on my system) is related to ZEND_VM_SPEC not being defined. zend_vm_def.h: 4567 #if !defined(ZEND_VM_SPEC) || (OP1_TYPE != IS_UNUSED) Results in all variants of ZEND_EXIT to become: #if 0 || ... There are only two references to ZEND_VM_SPEC in the code base, neither are defines. What does this control, where should it be defined? Previous Comments: [2012-02-04 17:56:08] the...@php.net Same goes for die(). [2012-02-04 17:54:03] the...@php.net Description: Calling exit with an int arg will not lead to PHP exiting with this exitcode. Test script: --- $ php -r 'exit(2);' ; echo $? Expected result: 2 Actual result: -- 254 -- Edit this bug report at https://bugs.php.net/bug.php?id=60978edit=1
Bug #60978 [Com]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978edit=1 ID: 60978 Comment by: php-dev at zerocue dot com Reported by:the...@php.net Summary:exit code incorrect Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: Actually my last post has nothing to do with it, mis-read the code. I don't see where the problem is, the executor_globals.exit_status is being set to two properly and the LONGJMP(bailout) still has the right exit_status value in the executor. I did confirm that this was fine in 5.3.10 but not in 5.4 or trunk. Previous Comments: [2012-02-04 19:44:24] php-dev at zerocue dot com Looks like this (on my system) is related to ZEND_VM_SPEC not being defined. zend_vm_def.h: 4567 #if !defined(ZEND_VM_SPEC) || (OP1_TYPE != IS_UNUSED) Results in all variants of ZEND_EXIT to become: #if 0 || ... There are only two references to ZEND_VM_SPEC in the code base, neither are defines. What does this control, where should it be defined? [2012-02-04 17:56:08] the...@php.net Same goes for die(). [2012-02-04 17:54:03] the...@php.net Description: Calling exit with an int arg will not lead to PHP exiting with this exitcode. Test script: --- $ php -r 'exit(2);' ; echo $? Expected result: 2 Actual result: -- 254 -- Edit this bug report at https://bugs.php.net/bug.php?id=60978edit=1
Bug #60978 [Com]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978edit=1 ID: 60978 Comment by: php-dev at zerocue dot com Reported by:the...@php.net Summary:exit code incorrect Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: This does not occur when executing a script file, only through -r. Previous Comments: [2012-02-04 19:59:37] php-dev at zerocue dot com Actually my last post has nothing to do with it, mis-read the code. I don't see where the problem is, the executor_globals.exit_status is being set to two properly and the LONGJMP(bailout) still has the right exit_status value in the executor. I did confirm that this was fine in 5.3.10 but not in 5.4 or trunk. [2012-02-04 19:44:24] php-dev at zerocue dot com Looks like this (on my system) is related to ZEND_VM_SPEC not being defined. zend_vm_def.h: 4567 #if !defined(ZEND_VM_SPEC) || (OP1_TYPE != IS_UNUSED) Results in all variants of ZEND_EXIT to become: #if 0 || ... There are only two references to ZEND_VM_SPEC in the code base, neither are defines. What does this control, where should it be defined? [2012-02-04 17:56:08] the...@php.net Same goes for die(). [2012-02-04 17:54:03] the...@php.net Description: Calling exit with an int arg will not lead to PHP exiting with this exitcode. Test script: --- $ php -r 'exit(2);' ; echo $? Expected result: 2 Actual result: -- 254 -- Edit this bug report at https://bugs.php.net/bug.php?id=60978edit=1
Bug #60978 [Com]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978edit=1 ID: 60978 Comment by: php-dev at zerocue dot com Reported by:the...@php.net Summary:exit code incorrect Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: Alright, in 5.3.10@php_cli:1023 the call to zend_eval_string_ex() never returned after a zend_bailout(), if it had this bug would have been present there because zend_bailout always returns FAILURE even in non-failure cases. In 5.4 and trunk, the zend_eval_string_ex() does return and hits the exit_status=254 line. The proper fix would be to have zend_bailout not return FAILURE unless it did fail but this is a much larger change. In this case the patch simply ignores the return state of the zend_eval_string_ex() and always returns the EG(exit_status) value. Previous Comments: [2012-02-04 20:00:43] php-dev at zerocue dot com This does not occur when executing a script file, only through -r. [2012-02-04 19:59:37] php-dev at zerocue dot com Actually my last post has nothing to do with it, mis-read the code. I don't see where the problem is, the executor_globals.exit_status is being set to two properly and the LONGJMP(bailout) still has the right exit_status value in the executor. I did confirm that this was fine in 5.3.10 but not in 5.4 or trunk. [2012-02-04 19:44:24] php-dev at zerocue dot com Looks like this (on my system) is related to ZEND_VM_SPEC not being defined. zend_vm_def.h: 4567 #if !defined(ZEND_VM_SPEC) || (OP1_TYPE != IS_UNUSED) Results in all variants of ZEND_EXIT to become: #if 0 || ... There are only two references to ZEND_VM_SPEC in the code base, neither are defines. What does this control, where should it be defined? [2012-02-04 17:56:08] the...@php.net Same goes for die(). [2012-02-04 17:54:03] the...@php.net Description: Calling exit with an int arg will not lead to PHP exiting with this exitcode. Test script: --- $ php -r 'exit(2);' ; echo $? Expected result: 2 Actual result: -- 254 -- Edit this bug report at https://bugs.php.net/bug.php?id=60978edit=1
Req #55828 [Com]: Instantiation and call in one expression.
Edit report at https://bugs.php.net/bug.php?id=55828edit=1
ID: 55828
Comment by: php-dev at zerocue dot com
Reported by:connec dot 2002 at gmail dot com
Summary:Instantiation and call in one expression.
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
There is an RFC documenting this request here:
https://wiki.php.net/rfc/instance-method-call
I believe one of the patches has been applied to the 5.4 branch per Felipe Pena
on 11/6/2011
Previous Comments:
[2011-10-04 18:21:00] mikko dot petteri dot hirvonen at gmail dot com
This feature is found on the 5.4 TODO list (https://wiki.php.net/todo/php54)
and
even a patch is available at https://wiki.php.net/rfc/instance-method-call, but
for reasons unknown it is not committed to 5.4 or even trunk.
[2011-10-04 18:10:15] design at oleku dot org
I totally agree ..
[2011-10-01 23:49:32] connec dot 2002 at gmail dot com
Description:
It would be nice if object instantiation and calling methods on the object
could
occur within the same expression.
Test script:
---
class A {
public function method() {
echo call\n;
}
}
new A(/* args, mayhaps */)-method();
new A-method();
Expected result:
call
call
Actual result:
--
Parse error: syntax error, unexpected '-'
--
Edit this bug report at https://bugs.php.net/bug.php?id=55828edit=1
