Req #48358 [Com]: SplDoublyLinkedList needs an insertAfterIterator() method or something similar
Edit report at http://bugs.php.net/bug.php?id=48358&edit=1 ID: 48358 Comment by: 1000235409 at smail dot shnu dot edn dot cn Reported by: dannel at aaronexodus dot com Summary: SplDoublyLinkedList needs an insertAfterIterator() method or something similar Status: Assigned Type:Feature/Change Request Package: Feature/Change Request PHP Version: 5.3.0RC2 Assigned To: colder New Comment: i have encountered the same problem today, after this was modified for 1 year... but i have a solution to solve this problem. write anohter class with a lots of spldoublylinkedlists inside it. however, complex algorithm may be used... Previous Comments: [2009-05-21 17:02:15] dannel at aaronexodus dot com Description: The SplDoublyLinkedList is great, but it lacks a way to insert a node somewhere in the middle of the list. One could technically extend the class and provide that functionality, but due to the fact that there seem to be [documented] data members in SplDoublyLinkedList, the only way to do it would be to find the reference node, insert the new node, and move all of the following nodes up one slot in the list, resulting in O(n) performance for an insert. I propose adding an insertAfterIterator() method which would place the new node after the current node the iterator points to. Another option could be an insertAfterArrayKey() method which would act similarly, but would find the reference node via a given array key, which might be a little more straightforward to use in code. Each should probably have an insertBefore*() counterpart as well. -- Edit this bug report at http://bugs.php.net/bug.php?id=48358&edit=1
[PHP-BUG] Bug #51886 [NEW]: call_user_func() does not propagate the scope
From:
Operating system: Debian 5.0
PHP version: 5.3SVN-2010-05-22 (snap)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:call_user_func() does not propagate the scope
Description:
call_user_func() does not propagate the scope when used in calls between
two classes that have no child-parent relation. When they have child-parent
relation as described in this bug entry:
http://bugs.php.net/bug.php?id=47402 it is fine.
As it is put in the "Backward Incompatible Changes" here:
http://www.php.net/manual/en/migration53.incompatible.php
"The call_user_func() family of functions now propagate $this even if the
callee is a parent class. ". I guess it has to do it for classes that have
no relation as well (or if not so the direct call t2::some_method() should
not do it either). As it is at the moment is inconsistent.
P.S. As well I think a better explanation with an example in the docs
should be added for "The call_user_func() family of functions now propagate
$this even if the callee is a parent class.". It is not clear at all what
it is about if one don't get onto the original bug entry:
"http://bugs.php.net/bug.php?id=47402";.
I didnt use the original 47402 entry as in fact it is not a bug.
Test script:
---
class t1
{
public function __call($method,$args) {
//call_user_func('t2::some_method',$args);//for PHP 5.3
call_user_func(array('t2','some_method'),$args);
t2::some_method();
}
public function existing_method() {
//call_user_func('t2::some_method');//for PHP 5.3
call_user_func(array('t2','some_method'));
t2::some_method();
}
}
class t2
{
public function some_method() {
print isset($this)?'yes':'no';
print PHP_EOL;
}
}
$t1 = new t1;
$t1->existing_method();
$t1->non_existing_method();//use overloading
Expected result:
yes
yes
yes
yes
Actual result:
--
no
yes
no
yes
--
Edit bug report at http://bugs.php.net/bug.php?id=51886&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51886&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51886&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51886&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51886&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51886&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51886&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51886&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51886&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51886&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51886&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51886&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51886&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51886&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51886&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51886&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51886&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51886&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51886&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51886&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51886&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51886&r=mysqlcfg
Bug #51880 [Opn->Asn]: Missfunction of mb_eregi() and mb_ereg()
Edit report at http://bugs.php.net/bug.php?id=51880&edit=1
ID: 51880
Updated by: fel...@php.net
Reported by: tnpaulik at gmail dot com
Summary: Missfunction of mb_eregi() and mb_ereg()
-Status: Open
+Status: Assigned
Type: Bug
Package: *Regular Expressions
Operating System: Windows, Linux, doesn't matter
PHP Version: Irrelevant
-Assigned To:
+Assigned To: moriyoshi
Previous Comments:
[2010-05-21 16:13:23] tnpaulik at gmail dot com
Description:
mb_eregi doesnt macht caseinsensitivity for non ASCII signs in PHP 5.2
and 5.3
Example:
mb_eregi('Ã','ü') returns false.
mb_ereg is case insensotoive for non ASCII charakters if i put tem in
[]
Example:
mb_ereg("[Ã]","ü") returns true.
Test script:
---
if (!mb_eregi("Ã","ü"))
echo "THAT shoudldn't be so...\n";
if (mb_ereg("[Ã]","ü"))
echo "THAT shoudldn't be so...\n";
Expected result:
no output
Actual result:
--
THAT shoudldn't be so...
THAT shoudldn't be so...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51880&edit=1
Bug #51826 [Opn]: maybe a wrong oop logic.
Edit report at http://bugs.php.net/bug.php?id=51826&edit=1
ID: 51826
User updated by: 1000235409 at smail dot shnu dot edu dot cn
Reported by: 1000235409 at smail dot shnu dot edu dot cn
Summary: maybe a wrong oop logic.
Status: Open
Type: Bug
Package: Class/Object related
Operating System: WINDOWS
PHP Version: 5.3SVN-2010-05-14 (SVN)
New Comment:
getType() . " VALUE=" . $this->FValue;
}
}
interface IParam {
public function getType(); //getType again.
}
class TStringParam extends TAbstractParam implements IParam {
public function getType() {return 'VARCHAR'; } //another getType, the
fatal
error goes here.
}
see this example, please...
Previous Comments:
[2010-05-18 01:35:34] 1000235409 at smail dot shnu dot edu dot cn
there are other non-abstract methods inside the abstract class to
provide some base behaviors for its children claclasses, which i omitted
in this example. and those non-abstract methods may call the abstract
methods. and an abstract class should not be defdefined as an instance
cclass for an interface cuz an non-abstract one should, so why
ambiguity?
[2010-05-17 19:51:45] crrodriguez at opensuse dot org
Expected behaviour, your code causes ambiguity.
[2010-05-14 17:42:35] 1000235409 at smail dot shnu dot edu dot cn
I have adapted those code(see it below) into delphi(object pascal, on
Delphi2010), however, nothing wrong at all. so i think it should be a
wrong oop
logic in php5(5.2 included also, since i've tested then...)
Type
TAbstractParam = Class(TInterfacedObject)
Procedure getType(); Virtual; Abstract;
End;
IParam = Interface
Procedure getType();
End;
TPrimativeParam = Class(TAbstractParam, IParam)
Procedure getType();
End;
//Other code omitted...
[2010-05-14 17:15:02] 1000235409 at smail dot shnu dot edu dot cn
Description:
A fatal error generates when a class extends from an abstract class and
implements
from an interface both with a same named abstract (all methods defined
inside
interfaces are abstract) method inside.
Test script:
---
http://bugs.php.net/bug.php?id=51826&edit=1
[PHP-BUG] Bug #51888 [NEW]: overloaded __set is called from parent class
From:
Operating system: Mac OS X
PHP version: 5.3.2
Package: Class/Object related
Bug Type: Bug
Bug description:overloaded __set is called from parent class
Description:
If you overwrite __set in a child class, the parent implementation is
called first
and than triggers the child version.
I found another bug, which says that you should implement the __set method
in the
parent class, but it in this case both methods are called.
A similar bug is reported in #44807, but it's only about the recursion
prevention.
Test script:
---
{$key} = $value . ' (Foo)';
}
}
class Bar extends Foo {
function __set($key, $value) {
$this->{$key} = $value . ' (Bar)';
}
function set() {
parent::__set('foobar', 'Test');
}
}
$bar = new Bar();
$bar->set();
echo $bar->foobar;
?>
Expected result:
Test (Foo)
Actual result:
--
Test (Foo) (Bar)
--
Edit bug report at http://bugs.php.net/bug.php?id=51888&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51888&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51888&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51888&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51888&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51888&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51888&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51888&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51888&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51888&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51888&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51888&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51888&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51888&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51888&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51888&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51888&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51888&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51888&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51888&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51888&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51888&r=mysqlcfg
Req #47794 [Com]: Theres no "ReflectionNamespace"
Edit report at http://bugs.php.net/bug.php?id=47794&edit=1 ID: 47794 Comment by: php-buigs at majkl578 dot cz Reported by: ka...@php.net Summary: Theres no "ReflectionNamespace" Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: * PHP Version: 5.3.0RC1 New Comment: bump Previous Comments: [2009-03-26 19:11:20] ka...@php.net Description: Currently theres no ReflectionNamespace class to reverse engineer namespaces, the Reflection* family already supports functions/classes with a namespace path but theres no class to dig deeper into namespaces with reflection. There was some plans about adding a ReflectionNamespace class within the README.namespaces file. -- Edit this bug report at http://bugs.php.net/bug.php?id=47794&edit=1
Bug #51824 [Fbk]: date('I') always return '0' in Windows
Edit report at http://bugs.php.net/bug.php?id=51824&edit=1
ID: 51824
Updated by: der...@php.net
Reported by: ng4rrjanbiah at rediffmail dot com
Summary: date('I') always return '0' in Windows
Status: Feedback
Type: Bug
Package: Date/time related
Operating System: Windows XP
PHP Version: 5.3.2
Assigned To: derick
New Comment:
Please provide expected and actual output.
Previous Comments:
[2010-05-21 16:41:20] ng4rrjanbiah at rediffmail dot com
@derik: Since, it's under loop, it may not make sense to put all
outputs.
However, if it's really needed, I can provide.
But, please check that the "I" specifier always returns 0 in Windows
(that
means, it doesn't handle DST-Daylight Saving correctly). Just run the
script in
Linux and Windows parallel and you'll notice the problem.
[2010-05-20 21:34:35] der...@php.net
Please provide expected and actual output.
[2010-05-20 19:51:59] paj...@php.net
Derick, what was the issue behind this specifier?
[2010-05-20 19:05:11] ng4rrjanbiah at rediffmail dot com
Bump! Anyone?
[2010-05-14 17:04:36] ng4rrjanbiah at rediffmail dot com
Description:
date('I') always return 0 in Windows; but returns according to DST in
Linux
Note: found http://bugs.php.net/13900 which is filed for PHP4 and
flagged as
"bogus"
Test script:
---
--
Edit this bug report at http://bugs.php.net/bug.php?id=51824&edit=1
Bug #51866 [Asn]: DateTime::createFromFormat does not match documentation
Edit report at http://bugs.php.net/bug.php?id=51866&edit=1 ID: 51866 Updated by: der...@php.net Reported by: smalyshev at sugarcrm dot com Summary: DateTime::createFromFormat does not match documentation Status: Assigned Type: Bug Package: Date/time related Operating System: * PHP Version: 5.3SVN-2010-05-20 (SVN) -Assigned To: derick +Assigned To: salathe New Comment: The docs are wrong here. If you specify a format letter, that information needs to be there. Previous Comments: [2010-05-21 00:05:22] s...@php.net I don't think it's a docs problem - it'd be much better if DateTime actually did what the docs say - at least as one of the options. Without it, if you have a string with date in it, you can not really find out where the date begins and ends and have no way to do parsing of partial dates. [2010-05-20 10:20:06] sala...@php.net I believe this is an issue of documentation rather than implementation, the quoted portion of the manual describes different behaviour than what the code appears to do. I'll assign this to Derick to confirm one way or the other. [2010-05-20 04:02:19] s...@php.net It also would be nice if this function could ignore extra input after the parsing and/or return where it stopped. [2010-05-20 04:01:27] smalyshev at sugarcrm dot com Description: The manual for DateTime::createFromFormat says: Format accepted by date(). If format does not contain the character ! then portions of the date/time value specified in format but not specified in time will be set to the current system time. However if you specify format like "d-m-Y H:i" and provide datetime string that does not contain time, parsing would fail - even though the manual says if time string does not contain parts from format it should use current system. Test script: --- string(19) "2007-10-25 18:58:31" ["timezone_type"]=> int(3) ["timezone"]=> string(19) "America/Los_Angeles" } Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=51866&edit=1
[PHP-BUG] Bug #51889 [NEW]: go-pear will fail, miserably
From: Operating system: Win32 PHP version: 5.3.2 Package: PHAR related Bug Type: Bug Bug description:go-pear will fail, miserably Description: go-pear.bat throws warnings and errors. C:\php5>go-pear.bat phar "C:\php5\PEAR\go-pear.phar" does not have a signature Warning: require_once(phar://go-pear.phar/index.php): failed to open stream: pha r error: invalid url or non-existent phar "phar://go-pear.phar/index.php" in C:\ php5\PEAR\go-pear.phar on line 1236 Press any key to continue . . . -- Edit bug report at http://bugs.php.net/bug.php?id=51889&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51889&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51889&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51889&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51889&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51889&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51889&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51889&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51889&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51889&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51889&r=support Expected behavior: http://bugs.php.net/fix.php?id=51889&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51889&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51889&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51889&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51889&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51889&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51889&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51889&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51889&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51889&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51889&r=mysqlcfg
[PHP-BUG] Bug #51890 [NEW]: CURL Problem
From: Operating system: Windows XP PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:CURL Problem Description: The script copy the URL into an existing file (robot.txt) The error occurs when you run the test script from the command line by providing the absolut path of your php.exe like >c:\php\php.exe test.php When you don't provide the absolut php path, the problem does not occure >php test.php Test script: --- http://www.astrobox.at/robots.txt";; $ch = curl_init($infile); $fo = fopen($outfile, "rb+" ); curl_setopt($ch, CURLOPT_FILE, $fo); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); curl_close($ch); fclose($fo); ?> Expected result: nothing Actual result: -- C:\phpda>c:\php\php.exe C:\phpda\test.php PHP Warning: curl_setopt(): the provided file handle is not writable in C:\phpda\test.php on line 7 Warning: curl_setopt(): the provided file handle is not writable in C:\phpda\test.php on line 7 User-agent: * Disallow: /administrator/ Disallow: /cache/ Disallow: /components/ Disallow: /editor/ Disallow: /help/ Disallow: /images/ Disallow: /includes/ Disallow: /language/ Disallow: /mambots/ Disallow: /media/ Disallow: /modules/ Disallow: /templates/ Disallow: /installation/ Disallow: /astrobox/produkte/ Disallow: /option/ -- Edit bug report at http://bugs.php.net/bug.php?id=51890&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51890&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51890&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51890&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51890&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51890&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51890&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51890&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51890&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51890&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51890&r=support Expected behavior: http://bugs.php.net/fix.php?id=51890&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51890&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51890&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51890&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51890&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51890&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51890&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51890&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51890&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51890&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51890&r=mysqlcfg
