Req #51531 [Com]: Adding additional backreferencing indicators for use with PREG_OFFSET_CAPTURE
Edit report at http://bugs.php.net/bug.php?id=51531&edit=1
ID: 51531
Comment by: mrjminer at gmail dot com
Reported by: mrjminer at gmail dot com
Summary: Adding additional backreferencing indicators for use
with PREG_OFFSET_CAPTURE
Status: Open
Type: Feature/Change Request
Package: *Regular Expressions
Operating System: All (AFAIK)
PHP Version: Irrelevant
New Comment:
By the way, "backreferencing indicator" is not a technical term, as far
as I know. I mean something along the lines of how '?:' indicates no
backreference should be captured.
Thanks for reading!
Previous Comments:
[2010-04-11 03:43:16] mrjminer at gmail dot com
Description:
This suggestion is related to PREG_MATCH_ALL when using
PREG_OFFSET_CAPTURE.
When specifying PREG_OFFSET_CAPTURE as a flag, each subpattern matched
results in the return of the subpatterned matched and the offset of the
subpattern matched in the $matches array. Yet, there are instances
where I may only need one of these pieces of information for a
particular subpattern match, but want the other piece (or both pieces)
of information for a different particular subpattern match within the
expression. In these instances, resources are being unnecessarily
wasted to store undesired information in the $matches array.
My suggestion is to add two additional indicators for backreference
capturing that can be used when the PREG_OFFSET_CAPTURE flags is
specified. These indicators would tell the engine to set the results of
either the offset or the subpattern string in the $matches array to
null. I believe this change would reduce the space required to hold the
information in $matches, while extending the typical functional use of
PREG_MATCH_ALL when used with PREG_OFFSET_CAPTURE (the same could also
be done for PREG_SPLIT and PREG_SPLIT_OFFSET_CAPTURE)
Test script:
---
Take, for instance, the following preg_match_all expressions to match
opening tags of BBCode:
1.
preg_match_all('/\\[(B|I|U|URL|COLOR|SIZE|LIST)(?:=([^]]*?))?](?=\\s*?[^\\s])/iu',$bbc,$openers,PREG_SET_ORDER|PREG_OFFSET_CAPTURE);
foreach($openers as $key => $val) {
foreach($val as $key2 => $val2) {
foreach($val2 as $key3 => $val3) {
echo '$openers['.$key.']['.$key2.']['.$key3.'] =
'.$val3.'';
}
}
}
2.
preg_match_all('/\\[(B|I|U|URL|COLOR|SIZE|LIST)(?:=([^]]*?))?](?=(\\s*?[^\\s]))/iu',$bbc,$openers,PREG_SET_ORDER|PREG_OFFSET_CAPTURE);
foreach($openers as $key => $val) {
foreach($val as $key2 => $val2) {
foreach($val2 as $key3 => $val3) {
echo '$openers['.$key.']['.$key2.']['.$key3.'] =
'.$val3.'';
}
}
}
Expected result:
In expression 1, the subpattern '(?=\\s*?[^\\s])' is used to check for
basic validity of an opening tag. The beginning of the contents of the
opening tag would have to be found using the offset of the whole match
($matches[#][0][1]) plus the length of the whole match
($matches[#][0][0]): $matches[#][0][1] + strlen($matches[#][0][0]) =
$contentstartposition.
In expression 2, the subpattern '(?=(\\s*?[^\\s]))' is used to check for
basic validity of an opening tag AND capture the position of where the
content starts in order to prevent performing a mathematical equation
and a strlen in order to find the starting position of the content:
$matches[#][3][1] = $contentstartposition.
In terms of processing power involved, expression 2 is superior to
expression 1, as it is merely relaying information already gathered and
known by the engine instead of performing addition and a strlen().
However, in terms of the resources required to store the match
information, expression 1 is superior to expression 2 and still ensures
a valid tag is found (but will require additional processing to get a
piece of information returned by expression 2).
The commonalities among both of these expressions:
-Neither requires the offsets for subpattern [1] or [2], merely the
contents of it (for parsing / filtering). The offsets are returned at
the expense of memory resources to store these unneeded offsets. The
only other alternative to obtaining only the contents of the match
without using the memory is to spend significant processing resources to
parse for the same contents the subpattern match returns in $matches.
-Neither requires the contents of the last subpattern (captured or not)
-- the offset is the only desired portion. In expression 1, the offset
must be attained by comprimising processing resources; in expression 2,
the offset is attained by comprimising memory resources.
If there were additional indicators to restrict the returned value in
$matches for each subpattern, the $matches array returned could requ
[PHP-BUG] Req #51531 [NEW]: Adding additional backreferencing indicators for use with PREG_OFFSET_CAPTURE
From:
Operating system: All (AFAIK)
PHP version: Irrelevant
Package: *Regular Expressions
Bug Type: Feature/Change Request
Bug description:Adding additional backreferencing indicators for use with
PREG_OFFSET_CAPTURE
Description:
This suggestion is related to PREG_MATCH_ALL when using
PREG_OFFSET_CAPTURE.
When specifying PREG_OFFSET_CAPTURE as a flag, each subpattern matched
results in the return of the subpatterned matched and the offset of the
subpattern matched in the $matches array. Yet, there are instances where I
may only need one of these pieces of information for a particular
subpattern match, but want the other piece (or both pieces) of information
for a different particular subpattern match within the expression. In
these instances, resources are being unnecessarily wasted to store
undesired information in the $matches array.
My suggestion is to add two additional indicators for backreference
capturing that can be used when the PREG_OFFSET_CAPTURE flags is specified.
These indicators would tell the engine to set the results of either the
offset or the subpattern string in the $matches array to null. I believe
this change would reduce the space required to hold the information in
$matches, while extending the typical functional use of PREG_MATCH_ALL when
used with PREG_OFFSET_CAPTURE (the same could also be done for PREG_SPLIT
and PREG_SPLIT_OFFSET_CAPTURE)
Test script:
---
Take, for instance, the following preg_match_all expressions to match
opening tags of BBCode:
1.
preg_match_all('/\\[(B|I|U|URL|COLOR|SIZE|LIST)(?:=([^]]*?))?](?=\\s*?[^\\s])/iu',$bbc,$openers,PREG_SET_ORDER|PREG_OFFSET_CAPTURE);
foreach($openers as $key => $val) {
foreach($val as $key2 => $val2) {
foreach($val2 as $key3 => $val3) {
echo '$openers['.$key.']['.$key2.']['.$key3.'] =
'.$val3.'';
}
}
}
2.
preg_match_all('/\\[(B|I|U|URL|COLOR|SIZE|LIST)(?:=([^]]*?))?](?=(\\s*?[^\\s]))/iu',$bbc,$openers,PREG_SET_ORDER|PREG_OFFSET_CAPTURE);
foreach($openers as $key => $val) {
foreach($val as $key2 => $val2) {
foreach($val2 as $key3 => $val3) {
echo '$openers['.$key.']['.$key2.']['.$key3.'] =
'.$val3.'';
}
}
}
Expected result:
In expression 1, the subpattern '(?=\\s*?[^\\s])' is used to check for
basic validity of an opening tag. The beginning of the contents of the
opening tag would have to be found using the offset of the whole match
($matches[#][0][1]) plus the length of the whole match ($matches[#][0][0]):
$matches[#][0][1] + strlen($matches[#][0][0]) = $contentstartposition.
In expression 2, the subpattern '(?=(\\s*?[^\\s]))' is used to check for
basic validity of an opening tag AND capture the position of where the
content starts in order to prevent performing a mathematical equation and a
strlen in order to find the starting position of the content:
$matches[#][3][1] = $contentstartposition.
In terms of processing power involved, expression 2 is superior to
expression 1, as it is merely relaying information already gathered and
known by the engine instead of performing addition and a strlen().
However, in terms of the resources required to store the match information,
expression 1 is superior to expression 2 and still ensures a valid tag is
found (but will require additional processing to get a piece of information
returned by expression 2).
The commonalities among both of these expressions:
-Neither requires the offsets for subpattern [1] or [2], merely the
contents of it (for parsing / filtering). The offsets are returned at the
expense of memory resources to store these unneeded offsets. The only
other alternative to obtaining only the contents of the match without using
the memory is to spend significant processing resources to parse for the
same contents the subpattern match returns in $matches.
-Neither requires the contents of the last subpattern (captured or not) --
the offset is the only desired portion. In expression 1, the offset must
be attained by comprimising processing resources; in expression 2, the
offset is attained by comprimising memory resources.
If there were additional indicators to restrict the returned value in
$matches for each subpattern, the $matches array returned could require
substantially less resources to store, while retaining its current
functionality and adding functionality to situations where it would not be
feasible to comprimise an increased use of memory resources for a decreased
use of CPU resources.
Thanks for your time!
--
Edit bug report at http://bugs.php.net/bug.php?id=51531&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51531&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51531&r=trysnapshot53
Try a snapshot (PHP 6.0):
[PHP-BUG] Bug #51530 [NEW]: DOMDocument::createElement() does not handle correctly
From:
Operating system: Fedora 12 GNU/Linux
PHP version: 5.3.2
Package: DOM XML related
Bug Type: Bug
Bug description:DOMDocument::createElement() does not handle correctly
Description:
DOMDocument::createElement() does not add a closing tag with
DOMDocument::createElement('link'). It outputs rather than
.
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
createDocument(null, null,
$implementation->createDocumentType('html'));
$html = $document->createElement('html');
$head = $document->createElement('head');
$stylesheet = $document->createElement('link');
$title = $document->createElement('title', 'Possible link error');
$body = $document->createElement('body');
$html->setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');
$stylesheet->setAttribute('href','style.css');
$stylesheet->setAttribute('rel','stylesheet');
$stylesheet->setAttribute('type','text/css');
$document->appendChild($html);
$html->appendChild($head);
$html->appendChild($body);
$head->appendChild($stylesheet);
$head->appendChild($title);
echo $document->saveHTML();
Expected result:
http://www.w3.org/1999/xhtml";>
Possible link error
Actual result:
--
http://www.w3.org/1999/xhtml";>
Possible link error
--
Edit bug report at http://bugs.php.net/bug.php?id=51530&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51530&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51530&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51530&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51530&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51530&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51530&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51530&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51530&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51530&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51530&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51530&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51530&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51530&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51530&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51530&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51530&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51530&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51530&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51530&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51530&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51530&r=mysqlcfg
Bug #51344 [Com]: FILTER_NULL_ON_FAILURE flag automatically set in filter_input() functions.
Edit report at http://bugs.php.net/bug.php?id=51344&edit=1 ID: 51344 Comment by: mats dot lindh at gmail dot com Reported by: pravila at alumni dot calpoly dot edu Summary: FILTER_NULL_ON_FAILURE flag automatically set in filter_input() functions. Status: Open Type: Bug Package: Filter related Operating System: Linux PHP Version: 5.2.13 New Comment: Patch to solve issue has been added. Patch is against current trunk but can probably be applied cleanly against 5.2 and 5.3 too. Issue stems from a simple error where RETURN_NULL(); and RETURN_FALSE; statements seems to have gotten mixed up. Test is also attached in patch, based on the example in the bug report. Previous Comments: [2010-03-21 18:02:46] pravila at alumni dot calpoly dot edu Description: * This is different than bug http://bugs.php.net/bug.php?id=41305 * The filter_var() vs. the filter_input() behave differently when using the FILTER_VALIDATE_BOOLEAN filter when the variable/input doesn't exist. More specifically, it seems as if the FILTER_NULL_ON_FAILURE flag is set automatically in the filter_input() function. (Note: same behavior for filter_var_array() vs. filter_input_array()). >From PHPINFO(): filter.default = unsafe_raw filter.default_flags = no value Revision: 1.52.2.39.2.16 Test script: --- Expected result: As per the documentation, we expect the output of the code above to be: bool(true) bool(false) bool(false) bool(true) bool(false) bool(false) Actual result: -- Even though the FILTER_NULL_ON_FAILURE flag is NOT set, we DO get a NULL value in the output: bool(true) bool(false) bool(false) bool(true) NULL bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=51344&edit=1
Bug #43834 [Com]: zend_mm_shutdown - Apache Crash
Edit report at http://bugs.php.net/bug.php?id=43834&edit=1 ID: 43834 Comment by: qq12345 at web dot de Reported by: jaco at jump dot co dot za Summary: zend_mm_shutdown - Apache Crash Status: No Feedback Type: Bug Package: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5.2CVS-2008-01-14 (snap) New Comment: For me the same: Since update to PHP 5.3.1 in conjunction with Apache 2.2.14 We have only 100 page impressions per day. By random per day around 4 crashes. Modul: php5ts.dll In the dump: Funktion: php5ts!zend_mm_shutdown 00dcc1b1 45 inc ebp 00dcc1b2 14ba adc al,0xba 00dcc1b4 0100 add [eax],eax 00dcc1b6 add [eax],al 00dcc1b8 8bcf mov ecx,edi 00dcc1ba d3e2 shl edx,cl 00dcc1bc f7d2 not edx 00dcc1be 23c2 and eax,edx 00dcc1c0 894514 mov [ebp+0x14],eax 00dcc1c3 e90d01 jmp php5ts!zend_mm_shutdown+0x1065 (00dcc2d5) 00dcc1c8 8b4f18 mov ecx,[edi+0x18] 00dcc1cb 33c0 xor eax,eax 00dcc1cd 85c9 testecx,ecx 00dcc1cf 0f95c0 setne al 00dcc1d2 8b4c8714 mov ecx,[edi+eax*4+0x14] 00dcc1d6 8d448714 lea eax,[edi+eax*4+0x14] 00dcc1da 85c9 testecx,ecx 00dcc1dc 741a jz php5ts!zend_mm_shutdown+0xf88 (00dcc1f8) 00dcc1de 8bf9 mov edi,ecx 00dcc1e0 8bd0 mov edx,eax 00dcc1e2 33c9 xor ecx,ecx 00dcc1e4 8b4718 mov eax,[edi+0x18] 00dcc1e7 85c0 testeax,eax 00dcc1e9 0f95c1 setne cl 00dcc1ec 8d448f14 lea eax,[edi+ecx*4+0x14] 00dcc1f0 8b4c8f14 mov ecx,[edi+ecx*4+0x14] 00dcc1f4 85c9 testecx,ecx 00dcc1f6 75e6 jnz php5ts!zend_mm_shutdown+0xf6e (00dcc1de) 00dcc1f8 c702 mov dword ptr [edx],0x0 00dcc1fe eb6a jmp php5ts!zend_mm_shutdown+0xffa (00dcc26a) FEHLER ->00dcc200 395f0c cmp [edi+0xc],ebx ds:0023:000c= 00dcc203 7505 jnz php5ts!zend_mm_shutdown+0xf9a (00dcc20a) 00dcc205 395908 cmp [ecx+0x8],ebx 00dcc208 7411 jz php5ts!zend_mm_shutdown+0xfab (00dcc21b) 00dcc20a 68c4cc1301 push0x113ccc4 00dcc20f e85cf6 callphp5ts!zend_mm_shutdown+0x600 (00dcb870) 00dcc214 8b4c2418 mov ecx,[esp+0x18] 00dcc218 83c404 add esp,0x4 00dcc21b 894f0c mov [edi+0xc],ecx 00dcc21e 897908 mov [ecx+0x8],edi 00dcc221 8b03 mov eax,[ebx] 00dcc223 3d1001 cmp eax,0x110 00dcc228 7339 jnb php5ts!zend_mm_shutdown+0xff3 (00dcc263) 00dcc22a 3bf9 cmp edi,ecx 00dcc22c 0f85a300 jne php5ts!zend_mm_shutdown+0x1065 (00dcc2d5) 00dcc232 c1e803 shr eax,0x3 00dcc235 83e802 sub eax,0x2 00dcc238 8b94c5d000 mov edx,[ebp+eax*8+0xd0] 00dcc23f 8b8cc5d400 mov ecx,[ebp+eax*8+0xd4] 00dcc246 3bd1 cmp edx,ecx 00dcc248 0f858700 jne php5ts!zend_mm_shutdown+0x1065 (00dcc2d5) 00dcc24e ba0100 mov edx,0x1 00dcc253 8bc8 mov ecx,eax 00dcc255 8b4510 mov eax,[ebp+0x10] 00dcc258 d3e2 shl edx,cl 00dcc25a f7d2 not edx 00dcc25c 23c2 and eax,edx 00dcc25e 894510 mov [ebp+0x10],eax 00dcc261 eb72 jmp php5ts!zend_mm_shutdown+0x1065 (00dcc2d5) 00dcc263 8b4310 mov eax,[ebx+0x10] 00dcc266 85c0 testeax,eax - Anwendungsausnahme aufgetreten: Anwendung: \xampp\apache\bin\httpd.exe (pid=2804) Wann: 31.03.2010 @ 04:58:57.478 Ausnahmenummer: c005 (Zugriffsverletzung) Funktion: php5ts!zend_mm_shutdown 00dcc2a0 cc int 3 00dcc2a1 f5 cmc 00dcc2a2 ??? 00dcc2a4 83c404 add esp,0x4 00dcc2a7 8b5714 mov edx,[edi+0x14] 00dcc2aa 8d4714 lea eax,[edi+0x14] 00dcc2ad 894210 mov [edx+0x10],eax 00dcc2b0 8b4318 mov eax,[ebx+0x18] 00dcc2b3 83c718 add
Bug #51523 [Opn->Csd]: Memory leak on fread()
Edit report at http://bugs.php.net/bug.php?id=51523&edit=1 ID: 51523 User updated by: evilzluk at gmail dot com Reported by: evilzluk at gmail dot com Summary: Memory leak on fread() -Status: Open +Status: Closed Type: Bug Package: Performance problem Operating System: Linux PHP Version: Irrelevant New Comment: resolved adding to cronjob: sync echo 1 > /proc/sys/vm/drop_caches echo 2 > /proc/sys/vm/drop_caches echo 3 > /proc/sys/vm/drop_caches sync Previous Comments: [2010-04-10 17:05:17] evilzluk at gmail dot com Description: The problem is the fread() uses a normal amount of a memory. But there are too many unallocated anonymous memory pages. So if the file size >2G the script may cause eating up to 2G of RAM. But the script's runtime memory is 5M. The problem is occured even if: $fp = fopen($file, "rb"); while(!feof($fp)) fread($fp, 1024); fclose($fp); After that the memory isn't released so we have a garbadge in the memory. Test script: --- Expected result: The total amount of a memory usage should be at least + 1024 (+ some buffer (up to 8192)). But not almost all the physical memory (0...unlimited) [2010-04-10 01:06:50] evilzluk at gmail dot com Description: The problem is the fread() uses a normal amount of a memory. But there are too many unallocated anonymous memory pages. So if the file size >2G the script may cause eating up to 2G of RAM. But the script's runtime memory is 5M. The problem is occured even if: $fp = fopen($file, "rb"); while(!feof($fp)) fread($fp, 1024); fclose($fp); After that the memory isn't released so we have a garbadge in the memory. Test script: --- Expected result: The total amount of a memory usage should be at least + 1024 (+ some buffer (up to 8192)). But not almost all the physical memory (0...unlimited) -- Edit this bug report at http://bugs.php.net/bug.php?id=51523&edit=1
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Comment by: weierophin...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
@johannes Perhaps an optional "strict" flag to is_callable() would
address this?
That would keep BC, while allowing for better checking for >= PHP-5
apps. Usage
would be:
$callback = array('Foo', 'bar');
if (is_callable($callback, true)) {
// Passed strict check
} else {
// failed strict check
}
Thoughts?
Previous Comments:
[2010-04-10 17:55:25] johan...@php.net
The method can always be called statically. The access to $this might be
forbidden but the method itself can be called. is_callable() doesn't
mean it will execute properly. (the $this error is basically the same as
a call to an undefined funciton in there or such)
To change this the only way would be to forbid calling non-static
methods statically. Maybe this can be done nowadays (we needed the
behavior for PHP 4 compatibility) but that's no bug but requires a RFC
and discussion on internals as this might break quite a few applications
(many PEAR-based things, many legacy applications not fully "converted"
to PHP 5 )
[2010-04-10 16:43:31] weierophin...@php.net
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
Bug #51524 [Com]: Class static method confusion
Edit report at http://bugs.php.net/bug.php?id=51524&edit=1
ID: 51524
Comment by: david71rj at gmail dot com
Reported by: david71rj at gmail dot com
Summary: Class static method confusion
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Windows 7/64
PHP Version: 5.3.2
New Comment:
Not make sense, a call static is call static, don't can exist $this. In
counterpart, if the user need pass a object reference, he must be to
specific
how a parameter.
public function x($object = null){
if($object
&& get_class($object) == 'B') {
// Now make sense, but not is $this
}
}
Bye.
Previous Comments:
[2010-04-10 18:06:02] paj...@php.net
Not sure you can simply bogus it "because that's the way php4 works" :)
Should we not fix it in trunk instead? Or at least leave that request
open until we have a decision.
[2010-04-10 17:49:31] johan...@php.net
If a static method is called from an object context the callers $this is
sent. This i due to compatibility with the way PHP 4 worked.
[2010-04-10 03:37:23] david71rj at gmail dot com
Description:
If I use public method as static in a method of a second function, this
send $this
from second class, don't of the first.
Test script:
---
http://codepad.org/8hW4Qtbo
Expected result:
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[3] <<< OKAY
2 => int 1
Actual result:
--
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test2)[3] < WHY "test2" IF DON'T?
2 => int 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51524&edit=1
Bug #50071 [Com]: Not honored: display_errors = stderr
Edit report at http://bugs.php.net/bug.php?id=50071&edit=1 ID: 50071 Comment by: ahollosi at xmp dot net Reported by: rank1seeker at gmail dot com Summary: Not honored: display_errors = stderr Status: Bogus Type: Bug Package: *Configuration Issues Operating System: FreeBSD 7.2 PHP Version: 5.3SVN-2009-11-03 (snap) New Comment: This bug is NOT bogus. I can confirm it for PHP 5.3.2 on IIS 7.5 running on Windows Server 2008 R2 (I'm using the precompiled binaries from windows.php.net) display_errors=stderr is ignored, output goes to STDOUT, if log_errors=On and error_log is set to a file. And yes: I checked that the correct php.ini file is loaded. (On a side note: I don't think that bug #28349 is bogus either. If I set display_errors=Off I excpect it to mean "Off" and not "Well, mostly off, unless you set some other configuration options to wrong values.") Previous Comments: [2009-11-04 13:50:12] rank1seeker at gmail dot com Of course it is loaded: I already use phpinfo() script Loaded Configuration File /usr/local/etc/php.ini I even tried: display_errors = stderr display_errors = Stderr display_errors = "stderr" display_errors = "Stderr" All behaves as: display_errors = On [2009-11-04 09:54:22] j...@php.net It works fine when your ini file is actually loaded. Check phpinfo() for "Loaded Configuration file" line.. [2009-11-03 23:18:29] rank1seeker at gmail dot com Description: display_errors = stderr, acts like display_errors = On Reproduce code: --- In php.ini: display_errors = stderr Expected result: Errors displayed to STDERR Actual result: -- Errors displayed to STDOUT (visible in browser) Some page[phpinfo();] parsed by fcgi Result(part): display_errors On(Local Value) On(Master Value) -- Edit this bug report at http://bugs.php.net/bug.php?id=50071&edit=1
Bug #51524 [Bgs->Opn]: Class static method confusion
Edit report at http://bugs.php.net/bug.php?id=51524&edit=1 ID: 51524 Updated by: paj...@php.net Reported by: david71rj at gmail dot com Summary: Class static method confusion -Status: Bogus +Status: Open Type: Bug Package: Scripting Engine problem Operating System: Windows 7/64 PHP Version: 5.3.2 New Comment: Not sure you can simply bogus it "because that's the way php4 works" :) Should we not fix it in trunk instead? Or at least leave that request open until we have a decision. Previous Comments: [2010-04-10 17:49:31] johan...@php.net If a static method is called from an object context the callers $this is sent. This i due to compatibility with the way PHP 4 worked. [2010-04-10 03:37:23] david71rj at gmail dot com Description: If I use public method as static in a method of a second function, this send $this from second class, don't of the first. Test script: --- http://codepad.org/8hW4Qtbo Expected result: array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[2] 2 => int 1 array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[3] <<< OKAY 2 => int 1 Actual result: -- array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[2] 2 => int 1 array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test2)[3] < WHY "test2" IF DON'T? 2 => int 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51524&edit=1
Bug #51527 [Opn->Bgs]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Updated by: johan...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
-Status: Open
+Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
The method can always be called statically. The access to $this might be
forbidden but the method itself can be called. is_callable() doesn't
mean it will execute properly. (the $this error is basically the same as
a call to an undefined funciton in there or such)
To change this the only way would be to forbid calling non-static
methods statically. Maybe this can be done nowadays (we needed the
behavior for PHP 4 compatibility) but that's no bug but requires a RFC
and discussion on internals as this might break quite a few applications
(many PEAR-based things, many legacy applications not fully "converted"
to PHP 5 )
Previous Comments:
[2010-04-10 16:43:31] weierophin...@php.net
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
Bug #51524 [Opn->Bgs]: Class static method confusion
Edit report at http://bugs.php.net/bug.php?id=51524&edit=1 ID: 51524 Updated by: johan...@php.net Reported by: david71rj at gmail dot com Summary: Class static method confusion -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Windows 7/64 PHP Version: 5.3.2 New Comment: If a static method is called from an object context the callers $this is sent. This i due to compatibility with the way PHP 4 worked. Previous Comments: [2010-04-10 03:37:23] david71rj at gmail dot com Description: If I use public method as static in a method of a second function, this send $this from second class, don't of the first. Test script: --- http://codepad.org/8hW4Qtbo Expected result: array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[2] 2 => int 1 array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[3] <<< OKAY 2 => int 1 Actual result: -- array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test)[2] 2 => int 1 array 0 => string 'static' (length=6) 1 => int 1 array 0 => string 'object' (length=6) 1 => object(test2)[3] < WHY "test2" IF DON'T? 2 => int 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51524&edit=1
Bug #51523 [Opn]: Memory leak on fread()
Edit report at http://bugs.php.net/bug.php?id=51523&edit=1 ID: 51523 User updated by: evilzluk at gmail dot com Reported by: evilzluk at gmail dot com Summary: Memory leak on fread() Status: Open Type: Bug Package: Performance problem Operating System: Linux PHP Version: Irrelevant New Comment: Description: The problem is the fread() uses a normal amount of a memory. But there are too many unallocated anonymous memory pages. So if the file size >2G the script may cause eating up to 2G of RAM. But the script's runtime memory is 5M. The problem is occured even if: $fp = fopen($file, "rb"); while(!feof($fp)) fread($fp, 1024); fclose($fp); After that the memory isn't released so we have a garbadge in the memory. Test script: --- Expected result: The total amount of a memory usage should be at least + 1024 (+ some buffer (up to 8192)). But not almost all the physical memory (0...unlimited) Previous Comments: [2010-04-10 01:06:50] evilzluk at gmail dot com Description: The problem is the fread() uses a normal amount of a memory. But there are too many unallocated anonymous memory pages. So if the file size >2G the script may cause eating up to 2G of RAM. But the script's runtime memory is 5M. The problem is occured even if: $fp = fopen($file, "rb"); while(!feof($fp)) fread($fp, 1024); fclose($fp); After that the memory isn't released so we have a garbadge in the memory. Test script: --- Expected result: The total amount of a memory usage should be at least + 1024 (+ some buffer (up to 8192)). But not almost all the physical memory (0...unlimited) -- Edit this bug report at http://bugs.php.net/bug.php?id=51523&edit=1
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Comment by: weierophin...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Open
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
Previous Comments:
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
Bug #51527 [Opn]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Updated by: paj...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Open
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
Previous Comments:
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
[PHP-BUG] Bug #51527 [NEW]: is_callable() returning true for non-static callbacks
From: weierophinney
Operating system: Linux
PHP version: 5.3.2
Package: Class/Object related
Bug Type: Bug
Bug description:is_callable() returning true for non-static callbacks
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any references
to
$this, it then fails with an E_FATAL, but otherwise it will run the method
as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods as
if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit bug report at http://bugs.php.net/bug.php?id=51527&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51527&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51527&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51527&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51527&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51527&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51527&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51527&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51527&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51527&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51527&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51527&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51527&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51527&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51527&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51527&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51527&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51527&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51527&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51527&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51527&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51527&r=mysqlcfg
