Bug->Req #55242 [Bgs]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
Edit report at https://bugs.php.net/bug.php?id=55242&edit=1 ID: 55242 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL Status: Bogus -Type: Bug +Type: Feature/Change Request Package:Safe Mode/open_basedir PHP Version:5.3.6 Block user comment: N Private report: N New Comment: - Previous Comments: [2011-09-16 04:12:20] spamik at yum dot pl >> Input (including file uploads) processing is done before the script is >> executed I know that, if it were not like that I would chagne it myself. Still a valid bug/feature request. [2011-09-15 15:57:44] il...@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 Input (including file uploads) processing is done before the script is executed, this means any ini_set() calls within the script won't matter. For that reason the setting remains as PHP_INI_SYSTEM. [2011-07-19 13:23:44] spamik at yum dot pl Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit this bug report at https://bugs.php.net/bug.php?id=55242&edit=1
Bug #55242 [Bgs]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
Edit report at https://bugs.php.net/bug.php?id=55242&edit=1 ID: 55242 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL Status: Bogus Type: Bug Package:Safe Mode/open_basedir PHP Version:5.3.6 Block user comment: N Private report: N New Comment: >> Input (including file uploads) processing is done before the script is >> executed I know that, if it were not like that I would chagne it myself. Still a valid bug/feature request. Previous Comments: [2011-09-15 15:57:44] il...@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 Input (including file uploads) processing is done before the script is executed, this means any ini_set() calls within the script won't matter. For that reason the setting remains as PHP_INI_SYSTEM. [2011-07-19 13:23:44] spamik at yum dot pl Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit this bug report at https://bugs.php.net/bug.php?id=55242&edit=1
Bug #55701 [Opn->Asn]: GlobIterator throws LogicException with message 'The parent constructor was not
Edit report at https://bugs.php.net/bug.php?id=55701&edit=1
ID: 55701
Updated by: fel...@php.net
Reported by:b...@php.net
Summary:GlobIterator throws LogicException with message 'The
parent constructor was not
-Status: Open
+Status: Assigned
Type: Bug
Package:SPL related
Operating System: Linux, OSX
PHP Version:5.3.8
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
Previous Comments:
[2011-09-15 13:42:30] b...@php.net
Description:
Basic functionality doesn't work because it seems as the GlobIterator might
needs
some changes to work with this commit:
http://marc.info/?l=php-cvs&m=130188548616717
Test script:
---
next();
} while($g->valid());
Expected result:
Empty output
Actual result:
--
PHP Fatal error: Uncaught exception 'LogicException' with message 'The parent
constructor
was not called: the object is in an invalid state ' in /private/tmp/x.php:6
Stack trace:
#0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex()
#1 {main}
thrown in /private/tmp/x.php on line 6
Fatal error: Uncaught exception 'LogicException' with message 'The parent
constructor was not
called: the object is in an invalid state ' in /private/tmp/x.php:6
Stack trace:
#0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex()
#1 {main}
thrown in /private/tmp/x.php on line 6
--
Edit this bug report at https://bugs.php.net/bug.php?id=55701&edit=1
[PHP-BUG] Bug #55704 [NEW]: php_flag engine off crashes apache
From: Operating system: Gentoo linux PHP version: 5.4SVN-2011-09-15 (snap) Package: Apache2 related Bug Type: Bug Bug description:php_flag engine off crashes apache Description: Since PHP 5.4 alpha 2 (alpha 1 still worked), apache crashes with a segmentation fault if "php_flag engine off" is anywhere in my apache configuration files. Test script: --- httpd.conf: ... php_flag engine off ... Expected result: PHP is disabled in whatever context "php_flag engine off" is used. Actual result: -- Apache crashes with a segmentation fault, even for a configtest (apache2 -t). Program received signal SIGSEGV, Segmentation fault. 0x704ddff9 in _zend_hash_add_or_update () from /usr/lib64/apache2/modules/libphp5.so -- Edit bug report at https://bugs.php.net/bug.php?id=55704&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55704&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55704&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55704&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55704&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55704&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55704&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55704&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55704&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55704&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55704&r=support Expected behavior: https://bugs.php.net/fix.php?id=55704&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55704&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55704&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55704&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55704&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55704&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55704&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55704&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55704&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55704&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55704&r=mysqlcfg
Req #55672 [Opn]: Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55672&edit=1 ID: 55672 Updated by: sh...@php.net Reported by:sh...@php.net Summary:Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php Status: Open Type: Feature/Change Request Package:*Configuration Issues PHP Version:trunk-SVN-2011-09-12 (SVN) Block user comment: N Private report: N New Comment: This patch is not about guessing php executable that runs run-tests.php, but is about php binary to be tested, these are often different binaries. Previous Comments: [2011-09-12 14:19:26] larue...@php.net how about use $0 ? [2011-09-12 12:29:48] sh...@php.net Description: Hello! I've made some improvements to run-tests.php: 1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if they're not provided, i.e. assume they have value 'auto'. You can still pass your own value as usual. Autoguessing is done this way: Looking for ./sapi/cli/php from the current directory, and, if not found from directory where run-tests.php script is resides (Christofer Jones suggestion). php-cgi is looked for the same way. 2) Added option -n (use no php.ini) to the shebang line (#!/usr/bin/php -n) so it would run more reliably on some hosts. My Ubuntu setup did not have E letter in variables_order (i.e. variables_order=GPCS) so $_ENV array was empty and some tests were skipped when they could be run. 3) Some better error handling of wrong paths So now you can run run-tests.php with just $ ./run-tests.php ext instead of $ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext You can also run run-tests.php from sub-dir, it will correctly guess 'auto' as well: $ cd ext/ $ ../run-tests.php zlib -- Edit this bug report at https://bugs.php.net/bug.php?id=55672&edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: sweiss at stylesight dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. Previous Comments: [2011-09-15 19:51:48] robin dot bussiek at googlemail dot com I am sorry to ask this for my understanding: Is it true, that the cause for this bug lies in a false inclusion of the "I" character in the Turkish character set - and therefore results in an unnecessary replacement? If so, my green knowledge leads me to the assumption, that a fix should be rather simple. **duck**, Robin [2011-08-08 12:02:30] tolga at profelis dot com dot tr php -v PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40) Problem continues! [2010-08-28 12:14:34] web-coder at list dot ru Thanks to Alexey dot Rybak at gmail dot com for a patch, that fix problem if you use only ASCII-symbols in functions/methods names: http://dev.badoo.com/custom_strtolower.diff [2010-08-27 19:17:55] web-coder at list dot ru Please tell me php version, where this problem is already solved. Thanks. [2010-08-09 07:55:30] stevemw at mac dot com +1. I get complaints about the side-effects of this on a weekly basis. Especially awful if you are asked to add turkish support after the fact, when you already have a large codebase. 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
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1
ID: 18556
Comment by: robin dot bussiek at googlemail dot com
Reported by:spud at nothingness dot org
Summary:Setting locale to 'tr_TR' lowercases class names
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Linux (RedHat 7.2)
PHP Version:5CVS, 4CVS (2005-10-04)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I am sorry to ask this for my understanding:
Is it true, that the cause for this bug lies in a false inclusion of the "I"
character in the Turkish character set - and therefore results in an
unnecessary replacement?
If so, my green knowledge leads me to the assumption, that a fix should be
rather simple.
**duck**,
Robin
Previous Comments:
[2011-08-08 12:02:30] tolga at profelis dot com dot tr
php -v
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Problem continues!
[2010-08-28 12:14:34] web-coder at list dot ru
Thanks to Alexey dot Rybak at gmail dot com for a patch,
that fix problem if you use only ASCII-symbols in functions/methods names:
http://dev.badoo.com/custom_strtolower.diff
[2010-08-27 19:17:55] web-coder at list dot ru
Please tell me php version, where this problem is already solved. Thanks.
[2010-08-09 07:55:30] stevemw at mac dot com
+1. I get complaints about the side-effects of this on a weekly basis.
Especially awful if you are asked to add turkish support after the fact, when
you
already have a large codebase.
[2010-06-13 20:07:58] ceremcem at cshus dot org
EDIT: The code that I used to regenerate this bug as follows:
foreach(get_declared_classes() as $class)
{
if(!class_exists($class))
echo "$class No Longer Exists!\n";
}
This code does not produce errors anymore but method names are still giving
this type of error.
I'm using ImageMagick and its PHP extension, imagick, which gives the error
"fatal: thumbnailImage() method not found", seems to be related with this bug.
When I rewrite the method name as ...->thumbnailimage(), all works OK.
So, the methods documented in http://www.php.net/manual/en/class.imagick.php
which include "I" (capital i), it can not be used without replacing "I" with
"i". (same errors occur with MagickWand class)
Could you please fix this too?
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
Req #54152 [Com]: Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi
Edit report at https://bugs.php.net/bug.php?id=54152&edit=1 ID: 54152 Comment by: f...@php.net Reported by:mark at catseye dot org Summary:Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi Status: Closed Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3SVN-2011-03-03 (snap) Assigned To:jimjag Block user comment: N Private report: N New Comment: reopen :) Previous Comments: [2011-09-15 19:08:11] apache-lists at riggs dot me This fix does not take into account using mod_proxy_balancer. When I use this same setup using mod_proxy_fcgi as a BalancerMember, I get a SCRIPT_FILENAME of proxy:balancer:// Should this be reopened to handle that, or should we create a new bug? [2011-03-29 13:39:13] mark at catseye dot org v3 of the patch was applied to trunk in r309054 http://svn.php.net/viewvc?view=revision&revision=309054 [2011-03-09 19:53:24] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309054 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 19:27:31] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309053 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 18:56:17] mark at catseye dot org Tested v3 of the patch against development snapshot php5.3-201103091530. Verified that the script gets executed, SCRIPT_FILENAME is set correctly, PATH_INFO is set correctly, and the php-fpm status page works. Compared output of phpinfo() between version 2 and version 3 of the patch for requests with extra-path components and query strings; did not find any discrepancies. Reviewed the patch itself and it looks good. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54152 -- Edit this bug report at https://bugs.php.net/bug.php?id=54152&edit=1
Req #54152 [Com]: Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi
Edit report at https://bugs.php.net/bug.php?id=54152&edit=1 ID: 54152 Comment by: apache-lists at riggs dot me Reported by:mark at catseye dot org Summary:Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi Status: Closed Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3SVN-2011-03-03 (snap) Assigned To:jimjag Block user comment: N Private report: N New Comment: This fix does not take into account using mod_proxy_balancer. When I use this same setup using mod_proxy_fcgi as a BalancerMember, I get a SCRIPT_FILENAME of proxy:balancer:// Should this be reopened to handle that, or should we create a new bug? Previous Comments: [2011-03-29 13:39:13] mark at catseye dot org v3 of the patch was applied to trunk in r309054 http://svn.php.net/viewvc?view=revision&revision=309054 [2011-03-09 19:53:24] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309054 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 19:27:31] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309053 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 18:56:17] mark at catseye dot org Tested v3 of the patch against development snapshot php5.3-201103091530. Verified that the script gets executed, SCRIPT_FILENAME is set correctly, PATH_INFO is set correctly, and the php-fpm status page works. Compared output of phpinfo() between version 2 and version 3 of the patch for requests with extra-path components and query strings; did not find any discrepancies. Reviewed the patch itself and it looks good. [2011-03-07 19:50:54] jim...@php.net please try v3 of the patch... This limits the later on version of the changes to just be in effect when we know we're handling the proxy:fcgi:// stuff The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54152 -- Edit this bug report at https://bugs.php.net/bug.php?id=54152&edit=1
Req #48674 [Com]: fopen() ftp wrapper and SIZE command
Edit report at https://bugs.php.net/bug.php?id=48674&edit=1
ID: 48674
Comment by: jesse at reltru dot com
Reported by:bmorel at ssi dot fr
Summary:fopen() ftp wrapper and SIZE command
Status: Open
Type: Feature/Change Request
Package:Streams related
Operating System: CentOS 5
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
Running into the same issue and would like to provide additional information
Ubuntu 10.04.3 LTS
PHP Version => 5.3.2-1ubuntu4.9
When using file_get_contents or fopen to connect to an FTP server that does not
support the SIZE command the process will exit early
wget works correctly
tcpdump -vvvnA shows the following for file_get_contents
220 FTP
USER *
331 Password required
PASS *
230 User logged in
TYPE I
200 Type set to I, binar
SIZE /*.***
500 Command not recogniz
221 You could at least s
Replaced username, pass and file with *'s but they are correct in the capture,
after the 221 the process ends and throws an exception.
Capturing a wget shows the following:
220 FTP
USER *
331 Password required
PASS *
230 User logged in
SYST
500 Command not recogniz
PWD
257 Current directory is
TYPE I
200 Type set to I, binar
CWD /*
250 Changed directory to
SIZE *.***
500 Command not recogniz
PASV
227 Entering Passive Mod
RETR *.***
150 Opening BINARY mode
Data is sent between FTP server and client successfully
Even though the attempt from wget to identify the file failed, it still
attempts to download the file and works successfully
Previous Comments:
[2009-06-24 11:15:50] bmorel at ssi dot fr
Description:
(Request for reopening bug #35765)
Sorry to restart this thread more than 3 years later, but I'm facing the very
same problem and cannot add a comment on a "won't fix" bug.
The problem concerns the fopen()'s ftp wrapper incorrectly relying on the ftp
SIZE command to check whether a file is downloadable.
I do think that's not a correct behaviour.
For example I'm using a ftp server from a well-known affiliate marketing
company, that's serving "virtual" files, that are not displayed in the ftp
server as such, but downloadable by any ftp client I could try... except php's
fopen wrapper.
The problem is that this server returns a "550 Not a plain file" error for a
SIZE request. This is not a plain file, but it is perfectly downloadable.
The SIZE command is *not* standardized in RFC 959. It may be used by ftp
clients, but only to try to get some information about the file.
Refusing to download a file due to a SIZE command failing is not RFC compliant,
while the servers the previous bug reporter and I are using, are.
Reproduce code:
---
$fp = fopen("ftp://example.com/test.xml.gz";, "rb");
var_dump($fp);
Expected result:
bool(true)
Actual result:
--
Warning: fopen(ftp://example.com/test.xml.gz) [function.fopen]: failed to open
stream: FTP server reports 550 /test.xml.gz: not a plain file.
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=48674&edit=1
Bug #55242 [Opn->Bgs]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
Edit report at https://bugs.php.net/bug.php?id=55242&edit=1 ID: 55242 Updated by: il...@php.net Reported by:spamik at yum dot pl Summary:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL -Status: Open +Status: Bogus Type: Bug Package:Safe Mode/open_basedir PHP Version:5.3.6 Block user comment: N Private report: N 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 Input (including file uploads) processing is done before the script is executed, this means any ini_set() calls within the script won't matter. For that reason the setting remains as PHP_INI_SYSTEM. Previous Comments: [2011-07-19 13:23:44] spamik at yum dot pl Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit this bug report at https://bugs.php.net/bug.php?id=55242&edit=1
Bug #55559 [Opn->Bgs]: ReflectionClass::getProperties() wrongly returns static properties
Edit report at https://bugs.php.net/bug.php?id=9&edit=1
ID: 9
Updated by: il...@php.net
Reported by:info at strictcoding dot co dot uk
Summary:ReflectionClass::getProperties() wrongly returns
static properties
-Status: Open
+Status: Bogus
Type: Bug
Package:Reflection related
Operating System: Fedora 15
PHP Version:5.3SVN-2011-08-31 (SVN)
Block user comment: N
Private report: N
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
The purpose would be to allow you to retrieve only the static properties, no
bug
here.
Previous Comments:
[2011-08-31 23:40:55] info at strictcoding dot co dot uk
I can see your point, however what would be the purpose of IS_STATIC then?
The whole point of the filter parameter, IMO, is to ask for a property which
either IS_PUBLIC, or IS_PUBLIC *and* IS_STATIC.
[2011-08-31 22:28:57] johan...@php.net
A static property is also a public property. I can see where you are coming
from but I'm not sure I want to follow the logic. Maybe we'd need "negative"
filters, while this makes it quite complex so I'd then again prefer filtering
it from the outside.
As then you really have all the freedom.
$non_private_properties = array_filter($r->getProperties(), function ($p) {
return !$p->isPublic(); });
[2011-08-31 22:14:27] info at strictcoding dot co dot uk
Description:
When used without ReflectionProperty::IS_STATIC,
ReflectionClass::getProperties()
still returns static properties.
Test script:
---
class A {
public static $x;
}
$r = new ReflectionClass('A');
print_r($r->getProperties(ReflectionProperty::IS_PUBLIC));
Expected result:
Array
(
)
Actual result:
--
Array
(
[0] => ReflectionProperty Object
(
[name] => x
[class] => A
)
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=9&edit=1
Req #55654 [Com]: ereg() behavior for preg_match
Edit report at https://bugs.php.net/bug.php?id=55654&edit=1 ID: 55654 Comment by: ni...@php.net Reported by:imaggens at gmail dot com Summary:ereg() behavior for preg_match Status: Open Type: Feature/Change Request Package:Regexps related Operating System: Windows 7 PHP Version:5.3SVN-2011-09-09 (snap) Block user comment: N Private report: N New Comment: I don't know what your exact use case is, but ... if you want to check that a string is a float, you should surround the regex with ^ and $ anchors. I.e. it will match the complete string, not just parts of it. ... if you are searching for floats in a longer text, you could simply use a negative lookahead assertion (?![0-9]) to ensure it isn't followed by a number. If neither are what you need, could you maybe explain your problem further? Previous Comments: [2011-09-09 12:30:43] imaggens at gmail dot com Description: Consideration. I choosen "September Snapshot", because I could not find mine in the list. My installation report to "PHP 5.3.3. Build Date: Jul 21 2010 20:25:38". Alright. I would like to ask, if is there any possibility to add, maybe through another non-Perl compatible modifier, the behavior we had with ereg(). The behavior I'm talking about refers to match as much as possible instead of stop at very first valid match. This is useful sometimes. In my case, specially to validate input data against a RFC specification. Look at this snippet: https://ideone.com/sC6mA I tried to make it as much specific as I could. The intention was to validate float point numbers, between zero and 1, with none and up to three decimals, denying invalid floats, such as 0.00 (same as zero) or 1.0 (same as 1). But, the "lazy" behavior of preg_match() is accepting the code above, where 0.3444 should be denied, because of its 4 decimals. But since 0.344 is valid in the last length verification (one and up to three), the function accepts the input data, and the last digit is simply ignored, because preg_match() already caracterized 0.344 as valid. I hope you understand Expected result: An empty array Actual result: -- A match -- Edit this bug report at https://bugs.php.net/bug.php?id=55654&edit=1
Bug #43082 [Com]: PHP exits without output on selecting null values
Edit report at https://bugs.php.net/bug.php?id=43082&edit=1
ID: 43082
Comment by: hsomel at hotmail dot com
Reported by:php at danielknell dot co dot uk
Summary:PHP exits without output on selecting null values
Status: No Feedback
Type: Bug
Package:ODBC related
Operating System: fedora7
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
Hello,
How do I go about removing a patch (odbc-64bits-len.patch) and then
re-compiling php.
Thanks
Previous Comments:
[2011-01-10 20:55:16] niv at tra dot cx
There seems to be at least a temporary solution, which is to uninstall the
patch
odbc-64bits-len.patch
[2009-12-08 14:05:03] zvika at zend dot com
Got this happening on Redhat5.4 64bit with Zend Server 4.0.6 PHP 5.2.11,
unixODBC-2.2.11-7.1, mysql-connector-odbc-3.51.26r1127-1.el5
MySQL schema:
CREATE TABLE `test_null` (
`col1` char(5) default NULL,
`col2` char(20) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO `test_null` VALUES ('AA','AA1'),('BB',NULL);
Ran a simple PHP script to select values using odbc_connect(DSN) +
odbc_exec(select)
Apache crashed on odbc_fetch_array() with core dump, I followed php.net
recommendation for debugging and here is the summary:
full backtrace up to first "execute" (frame 11)
(gdb) bt full
#0 0x2b47dc9d246e in malloc_consolidate () from /lib64/libc.so.6
No symbol table info available.
#1 0x2b47dc9d4a1a in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#2 0x2b47dc9d6bee in malloc () from /lib64/libc.so.6
No symbol table info available.
#3 0x2b47dca48094 in backtrace_symbols () from /lib64/libc.so.6
No symbol table info available.
#4 0x2b47f716f24a in print_backtrace () at ZendExtUtil.c:57
array = {0x2b47f716f23a, 0x2b47f716f2d5, 0x2b47dc9922d0,
0x2b47dc9de06b, 0x2b47e7186608,
0x2b47f228ddfe, 0x2b47e71c0ce2, 0x2b47e71bfc5c, 0x2b47fcacb842,
0x2b47fd2ea879}
size = 10
strings =
#5 0x2b47f716f2d5 in segvwait () at ZendExtUtil.c:383
No locals.
#6
No symbol table info available.
#7 0x2b47dc9de06b in memcpy () from /lib64/libc.so.6
No symbol table info available.
#8 0x2b47e7186608 in _estrndup (s=0x2b47fdf1da20 "AA1", length=)
at /php-5.2.11/Zend/zend_alloc.c:2444
p = 0x2b47fdff1fe8 "\220?סG+"
#9 0x2b47f228ddfe in ?? () from /usr/local/zend/lib/php_extensions/odbc.so
No symbol table info available.
#10 0x2b47e71c0ce2 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffb2d46fb0)
at /php-5.2.11/Zend/zend_vm_execute.h:200
return_reference = 0 '\0'
opline = (zend_op *) 0x2b47f89fbf60
original_return_value =
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 2097152
should_change_scope = 0 '\0'
#11 0x2b47e71bfc5c in execute (op_array=0x2b47fdf1d228) at
/php-5.2.11/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x2b47f89fbf60, function_state =
{function_symbol_table = 0x3,
function = 0x2b47f85a6d20, reserved = {0x2b47dac9cd15, 0x2b470001, 0x0,
0x23}}, fbc = 0x0,
op_array = 0x2b47fdf1d228, object = 0x0, Ts = 0x7fffb2d46f50, CVs =
0x7fffb2d46f20,
original_in_execution = 0 '\0', symbol_table = 0x2b47e7780308,
prev_execute_data = 0x0,
old_error_reporting = 0x0}
...
...
(gdb) frame 11
#11 0x2b47e71bfc5c in execute (op_array=0x2b47fdf1d228) at
/php-5.2.11/Zend/zend_vm_execute.h:92
92 /php-5.2.11/Zend/zend_vm_execute.h: No such file or directory.
in /php-5.2.11/Zend/zend_vm_execute.h
(gdb) print (char
*)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x2b47f228fba4 "odbc_fetch_array"
(gdb)
Is there anything I can run on the machine / Core dump to give you more
information?
Thanks
Zvika
[2007-11-02 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-10-25 13:42:57] j...@php.net
You need to compile PHP with --enable-debug set in your configure line to get
an useful backtrace.
[2007-10-25 13:41:41] php at danielknell dot co dot uk
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496243712 (LWP 7734)]
0x005aa9da in _zend_hash_add_or_update ()
(gdb) bt
#0 0x005aa9da in _zend_hash_add_or_updat
Bug #54684 [Com]: SoapServer->handle() breaks type hinting
Edit report at https://bugs.php.net/bug.php?id=54684&edit=1
ID: 54684
Comment by: henning dot panke at erento dot com
Reported by:luke at cywh dot com
Summary:SoapServer->handle() breaks type hinting
Status: Open
Type: Bug
Package:SOAP related
Operating System: Mac OS X 10.6
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Can reproduce this issue on a gentoo system with php 5.2.17.
Previous Comments:
[2011-05-07 02:55:44] luke at cywh dot com
Description:
SoapServer's handle() function breaks PHPs type-hinting for function parameters.
Note that if you remove "$server->handle()" you get the expected result. If you
leave it there you get the actual result.
If this is intended it might have to do with SoapServer passing back stdClass
as function arguments. But please note that this test code is not even used by
SoapServer. I merely call the handle() function and every function call is
effected, not just those invoked by SoapServer. Also for functions invoked by
SoapServer, shouldn't a string fail because it's a non-object?
If this isn't going to be fixed because it's a "feature" then we have a
documentation problem. There needs to be a warning on the handle()
documentation that states type-hinting is broken globally.
If this was intended, I honestly don't think this should happen on a global
scope. Only functions called by SoapServer should be effected, and even then
the type should be at least restricted to an object.
Test script:
---
$server = new \SoapServer(NULL, array('uri' => 'http://localhost'));
$server->handle();
class test
{
public function sayHello(Blah $one, $two)
{
return $one;
}
}
$test = new test;
var_dump($test->sayHello('one', 'two'));
Expected result:
Catchable fatal error: Argument 1 passed to test::sayHello() must be an
instance of Blah, string given
Actual result:
--
string(3) "one"
--
Edit this bug report at https://bugs.php.net/bug.php?id=54684&edit=1
Bug #55696 [Com]: __CLASS__ includes the namespace definition
Edit report at https://bugs.php.net/bug.php?id=55696&edit=1 ID: 55696 Comment by: ni...@php.net Reported by:dohpaz dot php at dohpaz dot com Summary:__CLASS__ includes the namespace definition Status: Open Type: Bug Package:Unknown/Other Function PHP Version:5.3.8 Block user comment: N Private report: N New Comment: As I see it "Foo\Bar" is the expected result. __CLASS__ returns the class name. And the class name is "Foo\Bar", not "Bar". An easy way to see this, is writing the following: $class = __CLASS__; $obj = new $class; This typical example (which would obviously be better written as just "$obj = new self;") would break if only "Bar" would be returned. Previous Comments: [2011-09-14 20:48:27] dohpaz dot php at dohpaz dot com Description: With the introduction of namespaces, the __CLASS__ magic constant has changed (without being documented) to include the current namespace as part of the class name. I submit that since there is a __NAMESPACE__ magic constant that the __CLASS__ constant should be reverted to its previous behavior. It seems more natural to concatenate __NAMESPACE__ and __CLASS__ to get a qualified name, rather than using basename() to get just the class name. At the very least, the documentation for namespaces (http://php.net/namespace), Magic Constants (http://us.php.net/manual/en/language.constants.predefined.php), and Backwards Incompatible Changes (http://us.php.net/manual/en/migration53.incompatible.php) should be updated to reflect this change. Test script: --- Expected result: I expect the above test script to return just the class name (i.e., Bar). Actual result: -- The test script above returns the qualified class name (i.e., Foo\Bar). -- Edit this bug report at https://bugs.php.net/bug.php?id=55696&edit=1
[PHP-BUG] Bug #55703 [NEW]: PHP crash when calling mysqli_fetch_fields
From: Operating system: Linux Ubuntu 11.04 PHP version: 5.3.8 Package: MySQLi related Bug Type: Bug Bug description:PHP crash when calling mysqli_fetch_fields Description: Hi, Running the attached test script causes a crash in mysqli extension (in every run). The crash comes from mysqli_api.c, at around line 1058: add_property_string(value, "catalog", (field->catalog ? field->catalog : ""), 1); The member field->catalog contains an address to an uninitialized pointer. Debugging libmysqlclient (self compiled, v5.1.58) shows that libmysqlclient simply left this member uninitialized, thus pointing to an uninitialized memory. To work around this bug, I modified my PHP sources locally so the "catalog" value is always set to "def" (which according to the documentation http://dev.mysql.com/doc/refman/5.0/en/c-api-data-structures.html is always true) (I also had a patch for libmysqlclient, but I am not sure where to send it...) This crash is reproducible in CLI mode using the test script attached. Attached is the patch to mysqli extension as well. Test script: --- https://bugs.php.net/bug.php?id=55703&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55703&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55703&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55703&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55703&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55703&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55703&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55703&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55703&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55703&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55703&r=support Expected behavior: https://bugs.php.net/fix.php?id=55703&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55703&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55703&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55703&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55703&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55703&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55703&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55703&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55703&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55703&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55703&r=mysqlcfg
Bug #55648 [Com]: CLI: the ini directives passed with -d to the CLI do not parse constants.
Edit report at https://bugs.php.net/bug.php?id=55648&edit=1 ID: 55648 Comment by: ni...@php.net Reported by:yaa...@php.net Summary:CLI: the ini directives passed with -d to the CLI do not parse constants. Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows 7 PHP Version:5.4SVN-2011-09-06 (snap) Block user comment: N Private report: N New Comment: Cannot reproduce on 5.4.0 Beta 1 on Windows 7: C:\php-5.4.0beta1>php.exe -d "error_reporting=E_ALL" -r "var_dump(error_reportin g());" int(32767) C:\php-5.4.0beta1>php.exe -d "error_reporting=E_ALL&~E_NOTICE" -r "var_dump(erro r_reporting());" int(32759) Output stays same if I add -n option. Previous Comments: [2011-09-08 18:49:40] yaa...@php.net Description: In posix-based systems, you can set error_reporting from the command line using the constants, but on Windows this always fails and results in an error_reporting() value of zero. This affects test automation, where these directives may be supplied in the INI section of a phpt test case. run-tests.php runs these tests by passing their ini- directives as -d. While run-tests.php explicitly sets the numeric value of these constants in the base ini, they do not get explicitly set in phpt-specific overrides. Thus, output may be different than expected. Test script: --- php.exe -n -d "error_reporting=E_ALL" -r "var_dump(error_reporting());" Expected result: int(32767) # or similar Actual result: -- int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=55648&edit=1
Bug #54089 [PATCH]: token_get_all with regards to __halt_compiler is not binary safe
Edit report at https://bugs.php.net/bug.php?id=54089&edit=1
ID: 54089
Patch added by: ni...@php.net
Reported by:nicolas dot grekas+php at gmail dot com
Summary:token_get_all with regards to __halt_compiler is not
binary safe
Status: Assigned
Type: Bug
Package:Unknown/Other Function
Operating System: Any
PHP Version:5.3.5
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: tokenizer_patch_full.txt
Revision: 1316097166
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch_full.txt&revision=1316097166
Previous Comments:
[2011-09-15 14:27:27] ni...@php.net
The following patch has been added/updated:
Patch Name: tokenizer_patch.txt
Revision: 1316096847
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch.txt&revision=1316096847
[2011-09-13 17:11:54] ni...@php.net
The following patch has been added/updated:
Patch Name: tokenizer_patch_full.txt
Revision: 1315933914
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch_full.txt&revision=1315933914
[2011-09-13 15:50:49] ni...@php.net
The following patch has been added/updated:
Patch Name: tokenizer_patch.txt
Revision: 1315929049
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch.txt&revision=1315929049
[2011-09-13 07:49:54] nicolas dot grekas+php at gmail dot com
Excerpt from internals:
Nikita PopovFri, Sep 9, 2011 at 09:15
[...]
The problem with the patch is, that there are some tokens after
T_HALT_COMPILER that are of interest, namely the '(' ')' ';'. After
the patch it is impossible to get those tokens, without either
relexing the code after T_HALT_COMPILER (that way you get the binary
data problem back, just with much more complex code) or writing a
regular expression to match it (which is really hard, as there may be
any token dropped by the PHP parser in there, i.e. whitespace,
comments, PHP tags).
[...]
I would like this patch to be reverted on the 5.4 and trunk branches.
I assume it's too late to revert it on 5.3, as it has been there for
some time already. It is just counterproductive. (Alternatively one
could fix token_get_all to return the (); tokens after
__halt_compiler, too, but that would be hard, probably.)
--
Ferenc Kovacs Fri, Sep 9, 2011 at 10:01
I think that it wouldn't be too hard.
>From a quick glance on the code, we should introduce a new local
variable, set that to true where we break now (
http://svn.php.net/viewvc/php/php-src/trunk/ext/tokenizer/tokenizer.c?view=markup#l155
) and don't break there but for the next ';'. another maybe less
confusing solution would be to explicitly add '(', ')' and ';' to the
result in the T_HALT_COMPILER condition before breking out of the
loop.
I will create a patch for this afternoon.
or could there be other important tokens after the __halt_compiler()
which should be present in the token_get_all() result?
--
Nicolas Grekas Fri, Sep 9, 2011 at 10:46
> don't break there but for the next ';'.
You can also just count the number of semantic token after T_HALT_COMPILER (ie
excluding whitespace and comments) and once you hit 3, halt.
> less confusing solution would be to explicitly add '(', ')' and ';' to the
> result in the T_HALT_COMPILER condition before breking out of the loop.
If you mean verifying that '(', ')' and (';' or T_CLOSE_TAG) are effectively
following T_HALT_COMPILER, I think that's part of the syntax analyser's job,
not tokenizer's.
If you're ok with this argument, then just couting 3 tokens is really the most
basic "syntax analysis" we have to do to fix the pb, don't you think?
> could there be other important tokens after the __halt_compiler()
> which should be present in the token_get_all() result?
Maybe the binary data itself, as a big T_INLINE_HTML for example ?
Also, if token_get_all you be made binary safe, that would be very cool ! (no
more eating of \x00-\x1F inside regular code) :)
--
Nikita PopovFri, Sep 9, 2011 at 19:39
> You can also just count the number of semantic token after T_HALT_COMPILER
> (ie excluding whitespace and comments) and once you hit 3, halt.
> [...]
> Maybe the binary data itself, as a big T_INLINE_HTML for example ?
In favor of both proposals!
Returning the next 3 tokens should be quite easy [1].
Returning the rest as an T_INLINE_HTML makes sense too, as extracting
the data is probably what you want. Though I have no idea how to
implement that ^^
[1]:
https://github.com/nikic/php-src/commit
Bug #54089 [PATCH]: token_get_all with regards to __halt_compiler is not binary safe
Edit report at https://bugs.php.net/bug.php?id=54089&edit=1
ID: 54089
Patch added by: ni...@php.net
Reported by:nicolas dot grekas+php at gmail dot com
Summary:token_get_all with regards to __halt_compiler is not
binary safe
Status: Assigned
Type: Bug
Package:Unknown/Other Function
Operating System: Any
PHP Version:5.3.5
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: tokenizer_patch.txt
Revision: 1316096847
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch.txt&revision=1316096847
Previous Comments:
[2011-09-13 17:11:54] ni...@php.net
The following patch has been added/updated:
Patch Name: tokenizer_patch_full.txt
Revision: 1315933914
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch_full.txt&revision=1315933914
[2011-09-13 15:50:49] ni...@php.net
The following patch has been added/updated:
Patch Name: tokenizer_patch.txt
Revision: 1315929049
URL:
https://bugs.php.net/patch-display.php?bug=54089&patch=tokenizer_patch.txt&revision=1315929049
[2011-09-13 07:49:54] nicolas dot grekas+php at gmail dot com
Excerpt from internals:
Nikita PopovFri, Sep 9, 2011 at 09:15
[...]
The problem with the patch is, that there are some tokens after
T_HALT_COMPILER that are of interest, namely the '(' ')' ';'. After
the patch it is impossible to get those tokens, without either
relexing the code after T_HALT_COMPILER (that way you get the binary
data problem back, just with much more complex code) or writing a
regular expression to match it (which is really hard, as there may be
any token dropped by the PHP parser in there, i.e. whitespace,
comments, PHP tags).
[...]
I would like this patch to be reverted on the 5.4 and trunk branches.
I assume it's too late to revert it on 5.3, as it has been there for
some time already. It is just counterproductive. (Alternatively one
could fix token_get_all to return the (); tokens after
__halt_compiler, too, but that would be hard, probably.)
--
Ferenc Kovacs Fri, Sep 9, 2011 at 10:01
I think that it wouldn't be too hard.
>From a quick glance on the code, we should introduce a new local
variable, set that to true where we break now (
http://svn.php.net/viewvc/php/php-src/trunk/ext/tokenizer/tokenizer.c?view=markup#l155
) and don't break there but for the next ';'. another maybe less
confusing solution would be to explicitly add '(', ')' and ';' to the
result in the T_HALT_COMPILER condition before breking out of the
loop.
I will create a patch for this afternoon.
or could there be other important tokens after the __halt_compiler()
which should be present in the token_get_all() result?
--
Nicolas Grekas Fri, Sep 9, 2011 at 10:46
> don't break there but for the next ';'.
You can also just count the number of semantic token after T_HALT_COMPILER (ie
excluding whitespace and comments) and once you hit 3, halt.
> less confusing solution would be to explicitly add '(', ')' and ';' to the
> result in the T_HALT_COMPILER condition before breking out of the loop.
If you mean verifying that '(', ')' and (';' or T_CLOSE_TAG) are effectively
following T_HALT_COMPILER, I think that's part of the syntax analyser's job,
not tokenizer's.
If you're ok with this argument, then just couting 3 tokens is really the most
basic "syntax analysis" we have to do to fix the pb, don't you think?
> could there be other important tokens after the __halt_compiler()
> which should be present in the token_get_all() result?
Maybe the binary data itself, as a big T_INLINE_HTML for example ?
Also, if token_get_all you be made binary safe, that would be very cool ! (no
more eating of \x00-\x1F inside regular code) :)
--
Nikita PopovFri, Sep 9, 2011 at 19:39
> You can also just count the number of semantic token after T_HALT_COMPILER
> (ie excluding whitespace and comments) and once you hit 3, halt.
> [...]
> Maybe the binary data itself, as a big T_INLINE_HTML for example ?
In favor of both proposals!
Returning the next 3 tokens should be quite easy [1].
Returning the rest as an T_INLINE_HTML makes sense too, as extracting
the data is probably what you want. Though I have no idea how to
implement that ^^
[1]:
https://github.com/nikic/php-src/commit/2d4cfa05947f04de447635ca5748b3b58defbfaf
(Not tested, only guessing)
--
Nikita PopovTue, Sep 13, 2011 at 09:16
I just set up an PHP environment and wrote a proper patch (including
test changes) to make it collect the next three tokens. It's a git
patch and I'm not sure whether it's compatible with SVN patches. I
would l
[PHP-BUG] Bug #55702 [NEW]: AMQP Exception handling
From:
Operating system: Linux
PHP version: 5.3.8
Package: Unknown/Other Function
Bug Type: Bug
Bug description:AMQP Exception handling
Description:
AMQPExchangeException, and possibly others, do not supply the error code in
$e->code, element. Only as a part of teh actual text message.
This makes error trapping slightly complex, slow and horrible.
Test script:
---
try{
$this->oProdExchange->declare($sName, $npExchangeType);
}catch(AMQPExchangeException $e){
$code = $e->getCode(); // $code = 0... always
}
Expected result:
If the exchange being used generates a:
[message:protected] => Server channel error: 406, message:
PRECONDITION_FAILED...
I would expect:
[code:protected] => 406 Not [code:protected] => 0
--
Edit bug report at https://bugs.php.net/bug.php?id=55702&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55702&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55702&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55702&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55702&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55702&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55702&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55702&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55702&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55702&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55702&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55702&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55702&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55702&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55702&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55702&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55702&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55702&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55702&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55702&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55702&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55702&r=mysqlcfg
[PHP-BUG] Bug #55701 [NEW]: GlobIterator throws LogicException with message 'The parent constructor was not
From:
Operating system: Linux, OSX
PHP version: 5.3.8
Package: SPL related
Bug Type: Bug
Bug description:GlobIterator throws LogicException with message 'The parent
constructor was not
Description:
Basic functionality doesn't work because it seems as the GlobIterator might
needs
some changes to work with this commit:
http://marc.info/?l=php-cvs&m=130188548616717
Test script:
---
next();
} while($g->valid());
Expected result:
Empty output
Actual result:
--
PHP Fatal error: Uncaught exception 'LogicException' with message 'The
parent
constructor
was not called: the object is in an invalid state ' in
/private/tmp/x.php:6
Stack trace:
#0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex()
#1 {main}
thrown in /private/tmp/x.php on line 6
Fatal error: Uncaught exception 'LogicException' with message 'The parent
constructor was not
called: the object is in an invalid state ' in /private/tmp/x.php:6
Stack trace:
#0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex()
#1 {main}
thrown in /private/tmp/x.php on line 6
--
Edit bug report at https://bugs.php.net/bug.php?id=55701&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55701&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55701&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55701&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55701&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55701&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55701&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55701&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55701&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55701&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55701&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55701&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55701&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55701&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55701&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55701&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55701&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55701&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55701&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55701&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55701&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55701&r=mysqlcfg
Req #55700 [Asn]: Disable automatic registration on a DOMXpath object.
Edit report at https://bugs.php.net/bug.php?id=55700&edit=1
ID: 55700
Updated by: paj...@php.net
Reported by:thomas at weinert dot info
Summary:Disable automatic registration on a DOMXpath object.
Status: Assigned
Type: Feature/Change Request
Package:DOM XML related
PHP Version:5.3.8
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
See https://bugs.php.net/bug.php?id=49490 as well
Previous Comments:
[2011-09-15 12:19:52] paj...@php.net
hi Rob!
Can you take a look pls? Afaict it is not BC but this behavior never really
works
:)
[2011-09-15 11:16:33] thomas at weinert dot info
Description:
DOMXpath currently registers namespaces of the current context or the document
element automatically. This results in broken and inconsistent results (Bug
#49490). An argument has been added to evaluate() and query() to change this
behavior. The current situation is that the argument and the context argument
has ALWAYS to be used to have predictable results.
A better way would be an option on the DOMXpath object.
An option would not only mean less code, it will also allow to just change one
part (initialization of ones DOMXpath instance), without the need to modify all
occurrences evaluate()/query() in existing source.
Test script:
---
loadXML(
''.
''.
''
);
$xpath = new DOMXPath($dom);
// disable automatic namespace registration
$xpath->enableRegisterNodeNS = FALSE;
$context = $dom->documentElement->firstChild;
$xpath->registerNamespace('a', 'urn:b');
var_dump(
$xpath->evaluate(
'descendant-or-self::a:*',
$context
)->item(0)->tagName
);
?>
Expected result:
string(5) "b:bar"
Actual result:
--
string(5) "a:foo"
--
Edit this bug report at https://bugs.php.net/bug.php?id=55700&edit=1
Req #55700 [Opn]: Disable automatic registration on a DOMXpath object.
Edit report at https://bugs.php.net/bug.php?id=55700&edit=1
ID: 55700
Updated by: paj...@php.net
Reported by:thomas at weinert dot info
Summary:Disable automatic registration on a DOMXpath object.
Status: Open
Type: Feature/Change Request
Package:DOM XML related
PHP Version:5.3.8
-Assigned To:
+Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
hi Rob!
Can you take a look pls? Afaict it is not BC but this behavior never really
works
:)
Previous Comments:
[2011-09-15 11:16:33] thomas at weinert dot info
Description:
DOMXpath currently registers namespaces of the current context or the document
element automatically. This results in broken and inconsistent results (Bug
#49490). An argument has been added to evaluate() and query() to change this
behavior. The current situation is that the argument and the context argument
has ALWAYS to be used to have predictable results.
A better way would be an option on the DOMXpath object.
An option would not only mean less code, it will also allow to just change one
part (initialization of ones DOMXpath instance), without the need to modify all
occurrences evaluate()/query() in existing source.
Test script:
---
loadXML(
''.
''.
''
);
$xpath = new DOMXPath($dom);
// disable automatic namespace registration
$xpath->enableRegisterNodeNS = FALSE;
$context = $dom->documentElement->firstChild;
$xpath->registerNamespace('a', 'urn:b');
var_dump(
$xpath->evaluate(
'descendant-or-self::a:*',
$context
)->item(0)->tagName
);
?>
Expected result:
string(5) "b:bar"
Actual result:
--
string(5) "a:foo"
--
Edit this bug report at https://bugs.php.net/bug.php?id=55700&edit=1
Req #52384 [Com]: PDOStatement::debugDumpParams does not emit the bind parameter value
Edit report at https://bugs.php.net/bug.php?id=52384&edit=1
ID: 52384
Comment by: php at nedge2k dot com
Reported by:jonah dot harris at gmail dot com
Summary:PDOStatement::debugDumpParams does not emit the bind
parameter value
Status: Open
Type: Feature/Change Request
Package:PDO related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
problem also exists in php 5.3 for windoze
Previous Comments:
[2010-09-29 01:22:44] cdotgutierrez at gmail dot com
I am seeing the same issue on PHP 5.3.3 on OSX. I've tried it using the same
test script that is provided in the original ticket.
[2010-07-20 23:43:12] jonah dot harris at gmail dot com
Description:
Per the PDO documentation, PDOStatement::debugDumpParams should emit the bind
parameter value. Currently however, it does not. Attached is a patch for 5.2
(which also applies cleanly to 5.3), which emits the bind parameter value.
Test script:
---
prepare('SELECT 1 WHERE 1 = :calories AND 2 = :colour');
if ($sth->bindParam(':calories', $calories, PDO::PARAM_INT) !== true)
die('die on ' . __LINE__. "\n");
if ($sth->bindValue(':colour', $colour, PDO::PARAM_STR) !== true)
die('die on ' . __LINE__. "\n");
$sth->debugDumpParams();
Expected result:
With Patch:
SQL : [len = 44] SELECT 1 WHERE 1 = :calories AND 2 = :colour
Params: 2
Key: Name: [9] :calories
paramno=-1
name=[9] ":calories"
is_param=1
param_type=1
value=150
Key: Name: [7] :colour
paramno=-1
name=[7] ":colour"
is_param=1
param_type=2
value=red
Actual result:
--
SQL: [44] SELECT 1 WHERE 1 = :calories AND 2 = :colour
Params: 2
Key: Name: [9] :calories
paramno=-1
name=[9] ":calories"
is_param=1
param_type=1
Key: Name: [7] :colour
paramno=-1
name=[7] ":colour"
is_param=1
param_type=2
--
Edit this bug report at https://bugs.php.net/bug.php?id=52384&edit=1
Bug #50982 [Asn->Csd]: incorrect assumption of PAGE_SIZE size
Edit report at https://bugs.php.net/bug.php?id=50982&edit=1 ID: 50982 Updated by: dmi...@php.net Reported by:geissert at debian dot org Summary:incorrect assumption of PAGE_SIZE size -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure PHP Version:5.3.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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: [2011-09-15 11:30:02] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=316812 Log: Fixed bug #50982 (incorrect assumption of PAGE_SIZE size) [2010-02-12 17:22:50] j...@php.net Related to bug #48034 Dmitry, please check this out. [2010-02-09 23:26:25] geissert at debian dot org Description: If sys/mman.h does not define PAGE_SIZE there's an incorrect assumption that it is 4096. This can have multiple side effects. At Debian we are going to use the following patch: http://git.debian.org/?p=pkg-php/php.git;a=blob;f=debian/patches/page_size_fixes.patch;h=f24b732ff6349101e1cee560b581081ca74d717f;hb=HEAD There's also a logical bug where PAGE_SIZE could not be defined at all but still used, but I'm not addressing that one. -- Edit this bug report at https://bugs.php.net/bug.php?id=50982&edit=1
[PHP-BUG] Req #55700 [NEW]: Disable automatic registration on a DOMXpath object.
From:
Operating system:
PHP version: 5.3.8
Package: DOM XML related
Bug Type: Feature/Change Request
Bug description:Disable automatic registration on a DOMXpath object.
Description:
DOMXpath currently registers namespaces of the current context or the
document element automatically. This results in broken and inconsistent
results (Bug #49490). An argument has been added to evaluate() and query()
to change this behavior. The current situation is that the argument and the
context argument has ALWAYS to be used to have predictable results.
A better way would be an option on the DOMXpath object.
An option would not only mean less code, it will also allow to just change
one part (initialization of ones DOMXpath instance), without the need to
modify all occurrences evaluate()/query() in existing source.
Test script:
---
loadXML(
''.
''.
''
);
$xpath = new DOMXPath($dom);
// disable automatic namespace registration
$xpath->enableRegisterNodeNS = FALSE;
$context = $dom->documentElement->firstChild;
$xpath->registerNamespace('a', 'urn:b');
var_dump(
$xpath->evaluate(
'descendant-or-self::a:*',
$context
)->item(0)->tagName
);
?>
Expected result:
string(5) "b:bar"
Actual result:
--
string(5) "a:foo"
--
Edit bug report at https://bugs.php.net/bug.php?id=55700&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55700&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55700&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55700&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55700&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55700&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55700&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55700&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55700&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55700&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55700&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55700&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55700&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55700&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55700&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55700&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55700&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55700&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55700&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55700&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55700&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55700&r=mysqlcfg
Bug #55475 [Csd->Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Updated by: dmi...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N New Comment: Reverted before the common decision. Previous Comments: [2011-09-15 10:59:23] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=316811 Log: Reverted the fix for #55475 (is_a() triggers autoloader) before the common decision [2011-09-15 10:00:16] dmi...@php.net I've committed the revert.is_a.behaviour.to.ignoring.strings.diff by alan at akbkhome dot com into 5.3. 5.4 is going to support string argument. [2011-09-15 09:58:17] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=316810 Log: Fixed bug #55475 (is_a() triggers autoloader). (alan at akbkhome dot com) [2011-09-07 06:30:47] vchernoivan at gmail dot com I guess it is no use to argue if the behaviuor is correct or not, or how precise the manual is. Since IT IS BREAKING EXISTING CODE, for me, too. Before the change if (is_a($date,"DateTime")) return $date->format(...); /// some code handling datetime strings worked just fine. Now it triggers __autoload and results in completely broken page. For sure, personally I can change every piece of MY OWN code. But consider users of tons of PHP libraries! What do you think, how long will it take to update every piece of them? Vote for reverting to prior-5.7 behavior until 5.4 [2011-08-29 07:15:47] tyr...@php.net "note the "FALSE otherwise" ..." note "if the object" ... Tyrael 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=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Bug #55475 [Asn->Csd]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
Updated by: dmi...@php.net
Reported by:mads at gartneriet dot dk
Summary:is_a() triggers autoloader
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I've committed the revert.is_a.behaviour.to.ignoring.strings.diff by alan at
akbkhome dot com into 5.3.
5.4 is going to support string argument.
Previous Comments:
[2011-09-15 09:58:17] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=316810
Log: Fixed bug #55475 (is_a() triggers autoloader). (alan at akbkhome dot com)
[2011-09-07 06:30:47] vchernoivan at gmail dot com
I guess it is no use to argue if the behaviuor is correct or not, or how
precise
the manual is. Since IT IS BREAKING EXISTING CODE, for me, too.
Before the change
if (is_a($date,"DateTime"))
return $date->format(...);
/// some code handling datetime strings
worked just fine. Now it triggers __autoload and results in completely broken
page.
For sure, personally I can change every piece of MY OWN code.
But consider users of tons of PHP libraries!
What do you think, how long will it take to update every piece of them?
Vote for reverting to prior-5.7 behavior until 5.4
[2011-08-29 07:15:47] tyr...@php.net
"note the "FALSE otherwise" ..."
note "if the object" ...
Tyrael
[2011-08-26 10:24:39] kkaminski at itens dot pl
+1 for reverting change in 5.3 branch and implementing it in 5.4 (or giving up
as it really CHANGES BEHAVIOR)
Currently __autoload throws Exceptions to break code execution on some
frameworks. This is clean solution as if developer makes a typo, code still can
handle missing class and for instance - display a dedicated error report.
Unfortunately, with your latest 'fix' all PEAR packages are now broken on
frameworks with __autoload + exceptions - due to isError implementation.
Are you really sure is it MY duty to rewrite / repatch all code (external) code
to work around your 'fix' ?
How I am supposed to handle missing classes in this case? With exceptions I can
catch everything and handle myself. Whats the other way?
[2011-08-24 05:16:11] jha dot rajeev at gmail dot com
I have a question re. the correct behavior of custom __autoload() functions
when
called from is_a() in 5.3.7. How do we handle/report missing classes? is is_a()
prepared to handle any sort of exceptions or does it assume that __autoload
will
return TRUE/FALSE only?
what if I just did something like is_a("",ABCD)?
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=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
Req #47660 [Asn->Csd]: open/close can be reduced for require_once in ZEND_INCLUDE_OR_EVAL handlers
Edit report at https://bugs.php.net/bug.php?id=47660&edit=1
ID: 47660
Updated by: dmi...@php.net
Reported by:basant dot kukreja at gmail dot com
Summary:open/close can be reduced for require_once in
ZEND_INCLUDE_OR_EVAL handlers
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
No changes required.
Previous Comments:
[2009-04-08 20:32:17] basant dot kukreja at gmail dot com
As I mentioned in my test case, that I tested with symlinks and it worked fine.
Meaning it included only once.
I will check php 5.3's open call performance.
Thanks for looking into this anyway.
[2009-04-01 10:52:58] dmi...@php.net
It looks like the patch doesn't care about symlinks.
Anyway, php-5.3 already has a general way for eliminating open() syscall on
require_once().
[2009-03-31 21:56:08] ras...@php.net
How does this handle the case where:
/some/path/to/file.php
/other/full/path/to/file.php
where /other is a symlink to /some ?
[2009-03-31 21:44:27] basant dot kukreja at gmail dot com
Here is the performance data collected :
For 30 minute 8 core measurement :
Before this patch :
__open 285.019 sec (Inclusive system time):
After this patch :
__open 124.747 sec (Inclusive system time):
So with submitted patch, specweb ecommerce benchmark spent 160 second less
time.
[2009-03-15 04:03:06] basant dot kukreja at gmail dot com
Why do php does so? Reason is obvious. For included_once files, php engine has
to make sure that files are included only once. A script can include a file
e.g
include_once "file1.php"
include_once "file2.php"
If file2.php is just a symlink to file1.php, it should not be included more
than once. So to assure that php engine calles zend_stream_open which will
eventually find the real path of the file and open the file.
However, if file is an absolute file then virtual_file_ex already finds the
real path so we can have a performance optimization for absolute paths.
Here is my suggested patch :
--
diff -r f55e0053325c php-5.2.9RC3/Zend/zend_vm_def.h
--- a/php-5.2.9RC3/Zend/zend_vm_def.h Wed Mar 11 12:43:20 2009 -0700
+++ b/php-5.2.9RC3/Zend/zend_vm_def.h Sat Mar 14 20:26:27 2009 -0700
@@ -2851,22 +2851,49 @@
case ZEND_INCLUDE_ONCE:
case ZEND_REQUIRE_ONCE: {
zend_file_handle file_handle;
+ char* realfilepath = NULL;
if (IS_ABSOLUTE_PATH(Z_STRVAL_P(inc_filename),
Z_STRLEN_P(inc_filename))) {
cwd_state state;
+ int virtfile_res = 0;
state.cwd_length = 0;
state.cwd = malloc(1);
state.cwd[0] = 0;
- failure_retval =
(!virtual_file_ex(&state, Z_STRVAL_P(inc_filename), NULL, 1) &&
+ virtfile_res = !virtual_file_ex(&state,
Z_STRVAL_P(inc_filename), NULL, 1);
+ failure_retval = (virtfile_res &&
zend_hash_exists(&EG(included_files), state.cwd, state.cwd_length+1));
+
+ if (virtfile_res && !failure_retval &&
(state.cwd[0] != 0)) {
+ realfilepath =
estrdup(state.cwd);
+ }
free(state.cwd);
}
if (failure_retval) {
/* do nothing */
+ } else if (realfilepath) {
+ /* file is a absolute file name and
virtual_file_ex succeeded */
+ int type =
(Z_LVAL(opline->op2.u.constant)==ZEND_INCLUDE_ONCE?ZEND_INCLUDE:ZEND_REQUIRE);
+ file_handle.filename = realfilepath;
+ file_handle.free_filename = 0;
+ file_handle.type = ZEND_HANDLE_FILENAME;
+ file_handle.opened_path = NULL;
+
Bug->Req #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1 ID: 55673 Updated by: dmi...@php.net Reported by:der...@php.net Summary:Compiler creates (unused) compiled variables for self::$foo Status: Assigned -Type: Bug +Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:5.3SVN-2011-09-12 (SVN) Assigned To:dmitry Block user comment: N Private report: N New Comment: yeah. the fix requires significant modification of grammar and compiler. It would be good to fix it, but I'm not sure it costs the time. In general it's not a bug, but a feature request. Previous Comments: [2011-09-15 03:59:43] larue...@php.net this cv is created in fetch_simple_variable_ex, and fetch_simple_variable_ex is used by a lot of logic, so I think we should alter the parse.y to make the class::$static_member not to denpend on a reference_variable. I have tried, but bring in new reduce conflict. [2011-09-14 15:29:34] larue...@php.net I'd better to report another one about the NOP opline, sorry agian. [2011-09-14 15:24:23] larue...@php.net OOPS!, I must lost my mind, what I was doing is erease NOP opline(god know How can I read this bug as "REMOVE UNUSED NOP" opline) sorry, but maybe this patch is also a litte useful... [2011-09-14 15:10:14] larue...@php.net I have made a patch for this, and make whole test after patched. made sure that there is no new test failed after patched. TEST RESULT: trunk: http://pastebin.com/gMYc2Fp5 5.4branch: http://pastebin.com/7EePEE43 5.3branch: http://pastebin.com/m4wirXjr [2011-09-14 15:07:01] larue...@php.net The following patch has been added/updated: Patch Name: bug55673.diff Revision: 1316012821 URL: https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821 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=55673 -- Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Bug #55695 [Asn->Wfx]: Compiler create unused opline(NOP)
Edit report at https://bugs.php.net/bug.php?id=55695&edit=1
ID: 55695
Updated by: dmi...@php.net
Reported by:larue...@php.net
Summary:Compiler create unused opline(NOP)
-Status: Assigned
+Status: Wont fix
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2011-09-14 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
PHP Compiler is targeted to be fast.
ZE allows to plug another compilers, opcode caches and optimizers to improve
the code quality if it's necessary.
The cost of a NOP instruction is invisible, so I don't think it makes sense to
invest into it.
Previous Comments:
[2011-09-14 15:34:14] larue...@php.net
Dmitry, as I said in #55673, sorry for that mis-fix, heh, anyway, I report this
to you, you can mark simply it as won't fix :)
[2011-09-14 15:32:52] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55695.diff
Revision: 1316014372
URL:
https://bugs.php.net/patch-display.php?bug=55695&patch=bug55695.diff&revision=1316014372
[2011-09-14 15:32:17] larue...@php.net
Description:
When having the following code:
The compiler generates compiled a totally unused NOP opline:
$ php -dvld.active=1 -r 'class foo { function bar() { self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
Test script:
---
no
--
Edit this bug report at https://bugs.php.net/bug.php?id=55695&edit=1
Req #27022 [Com]: Class constant has no visibility modificator
Edit report at https://bugs.php.net/bug.php?id=27022&edit=1
ID: 27022
Comment by: pulzarraider at gmail dot com
Reported by:and...@php.net
Summary:Class constant has no visibility modificator
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:5CVS-2004-01-23 (dev)
Block user comment: N
Private report: N
New Comment:
It would be great if php will have private/protected constants inside classes.
It's very important feature for every real object programming language. If it
would be available, the status of PHP, as a programming language, will grow.
Previous Comments:
[2004-01-23 12:47:45] and...@php.net
Description:
It is not possible to use visibility modificator like public/protected/private
on a class constant.
Reproduce code:
---
php -r "class fubar { protected const some_const = 123; }"
Actual result:
--
PHP Parse error: parse error, unexpected T_CONST, expecting T_VARIABLE in
Command line code on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=27022&edit=1
