Bug #52733 [Com]:
Edit report at http://bugs.php.net/bug.php?id=52733&edit=1 ID: 52733 Comment by: phpstars at gmail dot com Reported by:phpstars at gmail dot com Summary: Status: Bogus Type: Bug Package:Output Control Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: So the correct code: $array1 = array (2,3,1,5,4); $array2 = array (7,8,6,10,9); array_multisort($array1,$array2); Thanks for your attention Previous Comments: [2010-08-30 03:02:34] ras...@php.net That's not a bug. You are confused about how array_multisort() works. Read the documentation again and look at the examples. The output you are getting is the expected output. The second array is put in the same order as the first. [2010-08-30 02:50:54] phpstars at gmail dot com Description: I found this problem , use the latest version of XAMPP 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 8 [2] => 9 [3] => 7 [4] => 10 ) // Note : Number 7 in the $array2 sorted after number 9 echo ''; $array1 = array (4,3,1,5,2); $array2 = array (7,9,6,10,8); array_multisort($array1); array_multisort($array2); print_r ($array1); // Result : Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 7 [2] => 8 [3] => 9 [4] => 10 ) // Note : But when array_multisort($array2); separately was used, the output was correct ?> Test script: --- Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/bug.php?id=52733&edit=1
[PHP-BUG] Req #52734 [NEW]: Extend hypot() to three dimensions
From:
Operating system: Windows XP
PHP version: 5.3.3
Package: Math related
Bug Type: Feature/Change Request
Bug description:Extend hypot() to three dimensions
Description:
The existing hypot() function is limited to finding the hypotenuse of a
right-angled triangle in two dimensions ($h = hypot($x,$y)), when in fact
it is well-defined for higher dimensions as well as the length of the
diagonal of a (hyper)cuboid with edge lengths $x,$y,$z...; it's the square
root of the sum of the squares of the edge lengths.
For geometric purposes it would be helpful to have at least
hypot($x,$y,$z). The existing alternatives are sqrt($x*$x+$y*$y+$z*$z) or
hypot(hypot($x,$y),$z). The latter is (not surprisingly) markedly slower,
and also less accurate.
Test script:
---
function length($v1, $v2)
{
return hypot($v1[0]-$v2[0], $v1[1]-$v2[1], $v1[2]-$v2[2]);
}
$v1 = array(1, 1, 1);
$v2 = array(5, 6, 1);
echo length($v1, $v2);
Expected result:
6.4031242374328
Actual result:
--
A warning about hypot expecting exactly two parameters, and a NULL return
value.
--
Edit bug report at http://bugs.php.net/bug.php?id=52734&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52734&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52734&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52734&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52734&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52734&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52734&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52734&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52734&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52734&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52734&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52734&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52734&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52734&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52734&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52734&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52734&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52734&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52734&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52734&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52734&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52734&r=mysqlcfg
Bug #52733 [Opn->Bgs]:
Edit report at http://bugs.php.net/bug.php?id=52733&edit=1 ID: 52733 Updated by: ras...@php.net Reported by:phpstars at gmail dot com Summary: -Status: Open +Status: Bogus Type: Bug Package:Output Control Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: That's not a bug. You are confused about how array_multisort() works. Read the documentation again and look at the examples. The output you are getting is the expected output. The second array is put in the same order as the first. Previous Comments: [2010-08-30 02:50:54] phpstars at gmail dot com Description: I found this problem , use the latest version of XAMPP 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 8 [2] => 9 [3] => 7 [4] => 10 ) // Note : Number 7 in the $array2 sorted after number 9 echo ''; $array1 = array (4,3,1,5,2); $array2 = array (7,9,6,10,8); array_multisort($array1); array_multisort($array2); print_r ($array1); // Result : Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 7 [2] => 8 [3] => 9 [4] => 10 ) // Note : But when array_multisort($array2); separately was used, the output was correct ?> Test script: --- Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/bug.php?id=52733&edit=1
[PHP-BUG] Bug #52733 [NEW]:
From: Operating system: Windows 7 PHP version: 5.3.3 Package: Output Control Bug Type: Bug Bug description: Description: I found this problem , use the latest version of XAMPP 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 8 [2] => 9 [3] => 7 [4] => 10 ) // Note : Number 7 in the $array2 sorted after number 9 echo ''; $array1 = array (4,3,1,5,2); $array2 = array (7,9,6,10,8); array_multisort($array1); array_multisort($array2); print_r ($array1); // Result : Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) echo ''; print_r ($array2); // Result : Array ( [0] => 6 [1] => 7 [2] => 8 [3] => 9 [4] => 10 ) // Note : But when array_multisort($array2); separately was used, the output was correct ?> Test script: --- Expected result: Actual result: -- -- Edit bug report at http://bugs.php.net/bug.php?id=52733&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52733&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52733&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52733&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52733&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52733&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52733&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52733&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52733&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52733&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52733&r=support Expected behavior: http://bugs.php.net/fix.php?id=52733&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52733&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52733&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52733&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52733&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52733&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52733&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52733&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52733&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52733&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52733&r=mysqlcfg
Bug #52728 [Opn->Fbk]: realpath() fails to resolve symbolic links (symlinks) in remote file systems
Edit report at http://bugs.php.net/bug.php?id=52728&edit=1
ID: 52728
Updated by: paj...@php.net
Reported by:resonantmedia at gmail dot com
Summary:realpath() fails to resolve symbolic links
(symlinks) in remote file systems
-Status: Open
+Status: Feedback
Type: Bug
Package:Directory function related
Operating System: Ubuntu LTS 8.04
PHP Version:5.2.14
Block user comment: N
New Comment:
Please try using 5.3.3 or snapshot, using our sources, not patched
version of php.
Previous Comments:
[2010-08-29 22:50:05] resonantmedia at gmail dot com
I meant the magic constant __FILE__ (__FILENAME__) was a typo. Is there
a
changelog entry for 5.3 that refers to the issue?
[2010-08-29 14:25:51] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-29 10:18:08] resonantmedia at gmail dot com
Description:
php 5.2.4-2ubuntu5.7
Assuming a symbolic link refers to a script and both are on a remote
file system:
Calling realpath('./') does not produce the same results as
realpath(dirname(__FILENAME__)) when the script is being referred to by
its
symlink over NFS.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52728&edit=1
Bug #52728 [Fbk->Opn]: realpath() fails to resolve symbolic links (symlinks) in remote file systems
Edit report at http://bugs.php.net/bug.php?id=52728&edit=1
ID: 52728
User updated by:resonantmedia at gmail dot com
Reported by:resonantmedia at gmail dot com
Summary:realpath() fails to resolve symbolic links
(symlinks) in remote file systems
-Status: Feedback
+Status: Open
Type: Bug
Package:Directory function related
Operating System: Ubuntu LTS 8.04
PHP Version:5.2.14
Block user comment: N
New Comment:
I meant the magic constant __FILE__ (__FILENAME__) was a typo. Is there
a
changelog entry for 5.3 that refers to the issue?
Previous Comments:
[2010-08-29 14:25:51] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-08-29 10:18:08] resonantmedia at gmail dot com
Description:
php 5.2.4-2ubuntu5.7
Assuming a symbolic link refers to a script and both are on a remote
file system:
Calling realpath('./') does not produce the same results as
realpath(dirname(__FILENAME__)) when the script is being referred to by
its
symlink over NFS.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52728&edit=1
[PHP-BUG] Bug #52732 [NEW]: Docs say preg_match() returns FALSE on error, but it returns int(0)
From:
Operating system: Any
PHP version: 5.3.3
Package: PCRE related
Bug Type: Bug
Bug description:Docs say preg_match() returns FALSE on error, but it returns
int(0)
Description:
The documentation states that preg_match() will return the number of
matches (0 or
1) or bool(false) on error. The latter doesn't happenâpreg_match() is
returning
int(0) when an error occurs.
Test script:
---
http://us.php.net/preg_last_error
$ret = preg_match('/(?:\D+|<\d+>)*[!?]/', 'foobar foobar foobar');
echo 'Return value is ';
var_dump($ret);
if ($ret === false) {
echo '$ret is false; preg_last_error() says: ' . preg_last_error() .
"\n";
} else {
echo '$ret is not false; preg_last_error() says: ' . preg_last_error()
. "\n";
}
Expected result:
Return value is bool(false)
$ret is false; preg_last_error() says: 2
Actual result:
--
Return value is int(0)
$ret is not false; preg_last_error() says: 2
--
Edit bug report at http://bugs.php.net/bug.php?id=52732&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52732&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52732&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52732&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52732&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52732&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52732&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52732&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52732&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52732&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52732&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52732&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52732&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52732&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52732&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52732&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52732&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52732&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52732&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52732&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52732&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52732&r=mysqlcfg
Bug #30195 [Com]: scandir etc cannot read Chinese file/folder name
Edit report at http://bugs.php.net/bug.php?id=30195&edit=1
ID: 30195
Comment by: onekamil at gmail dot com
Reported by:percy at savant dot us
Summary:scandir etc cannot read Chinese file/folder name
Status: No Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: windows xp/2003
PHP Version:5CVS-2004-09-22 (dev)
Block user comment: N
New Comment:
Hi, have the same problem and my solution is: using
mb_convert_encoding.
$open = opendir($path);
foreach( $open as $value )
{
$value = mb_convert_encoding($value, mb_detect_order($value),
"UTF-8");
}
If saving file to folder using urlencode. To view using urldecode.
Previous Comments:
[2007-03-31 23:30:05] missingno at ifrance dot com
Same problem here.
On WinXP with PHP 5.2.0, using iso-8859-1 as charset for the system
(though the filesystem uses utf-8 for folders/files names).
I need to access folders whose names are encoded using UTF-8.
readdir/scandir won't allow me to do so (returning '?' for characters
outside the system charset).
The page is served like this:
header('Content-Type: text/html; charset=utf-8');
So the browser really isn't at fault.
Serving the document with a more specific charset is not an option since
I have to display texts in many different languages on the page.
As moleary at preg dot org suggested, it would be really nice to have an
option to force PHP to use a certain encoding while accessing the
filesystem. Or maybe, make it so that it uses the same encoding as the
filesystem instead of defaulting to iso-8859-1...
[2006-07-10 10:02:31] gandhavallakiran at yahoo dot co dot in
hi i have used the babel class in my coding of php. but it could not
read the characters of china and japan i.e. special characters. it is
displaying the blank space instead of china or japan text. could you
help me in this reacord how to display china characters in php. please
it is very urgent kindly help me.
[2005-02-25 01:00:07] 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".
[2005-02-17 15:22:16] moriyo...@php.net
Note that all of these are PHP code, so paste it within
.
[2005-02-17 15:20:57] moriyo...@php.net
You might have shown strings of a native encoding as
UTF-8 in your browser, most likely because of wrong
Content-Type.
Try putting one of the following at the top of your
script and let's see what'll happen:
CP936 (Simplified Chinese):
header('Content-Type', 'text/html; charset=GB2312');
CP949 (Korean):
header('Content-Type', 'text/html; charset=EUC-KR');
CP950 (Traditional Chinese):
header('Content-Type', 'text/html; charset=BIG5');
CP932 (Japanese):
header('Content-Type', 'text/html;
charset=Shift_JIS');
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
http://bugs.php.net/bug.php?id=30195
--
Edit this bug report at http://bugs.php.net/bug.php?id=30195&edit=1
Bug #52731 [Opn->Asn]: mb_strpos reports needle position incorrectly
Edit report at http://bugs.php.net/bug.php?id=52731&edit=1 ID: 52731 Updated by: fel...@php.net Reported by:tokul at users dot sourceforge dot net Summary:mb_strpos reports needle position incorrectly -Status: Open +Status: Assigned Type: Bug Package:mbstring related PHP Version:5.3SVN-2010-08-29 (snap) -Assigned To: +Assigned To:moriyoshi Block user comment: N Previous Comments: [2010-08-29 17:05:03] tokul at users dot sourceforge dot net Description: If code sets incorrect character set (utf-8 instead of big5 in test case), mb_strpos() can incorrectly report needle position in some cases. It looks like $offset is calculated one way and results are calculated in some other way. See test code. mb_substr($str,$pos1,1,'utf-8') can be used to see character that is in reported needle position. I understand that $str is not in UTF-8 charset, but position reported by mb_strpos() violates very basic strpos function behavior. Search is started after $offset position and result position is counted from string start. Result should not be lower than $offset or it should be boolean false. php5.3-201008291230 compiled with /configure --prefix=/somepath --enable-cli --disable-all --enable-mbstring Also tested PHP 5.2.0 (debian etch), 5.3.2-2 (debian squeeze) and 5.2.13 (standard PHP package). 5.2.13 and 5.3.2 results are the same. 5.2.0 results are a little bit different, but I was able to reproduce position calculation problem with more complex code. Test script: --- $str = "\xb7\x51 &\xb4\xa6\xb6\x7d"; $pos1 = mb_strpos($str,'&',0,'utf-8'); var_dump($pos1); $pos2 = mb_strpos($str,'&',$pos1 + 1,'utf-8'); var_dump($pos2); Expected result: second var_dump() result should be higher than first one or should be boolean false. result should not be lower than offset. Actual result: -- int(2) int(2) -- Edit this bug report at http://bugs.php.net/bug.php?id=52731&edit=1
Bug #52730 [Opn->Bgs]: Impossible to implement Interfaces with same method names
Edit report at http://bugs.php.net/bug.php?id=52730&edit=1
ID: 52730
Updated by: fel...@php.net
Reported by:wrzasq at gmail dot com
Summary:Impossible to implement Interfaces with same method
names
-Status: Open
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Debian
PHP Version:5.3.3
Block user comment: 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
There is a note in the documentation about this. See
http://docs.php.net/interface
Thanks.
Previous Comments:
[2010-08-29 15:43:13] wrzasq at gmail dot com
Sorry, a little misstake - of course classes B in case two and three
extend classes A.
[2010-08-29 13:02:13] wrzasq at gmail dot com
Description:
It's impossible to implement interfaces with same method names. Whath's
the most strange is, that you can simply "hack" this by implementing
each interface at different inheritance level.
(it's in fact PHP 5.3.2 issue, but I didn't see it fixed in PHP 5.3.3)
Test script:
---
first case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo, Bar
{
public function getID()
{
return 1;
}
}
second case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
}
third case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
public function getID()
{
return parent::getID();
}
}
Expected result:
Nothing at output, but all of them compile.
Actual result:
--
first case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
second case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
third case: worked fine
--
Edit this bug report at http://bugs.php.net/bug.php?id=52730&edit=1
[PHP-BUG] Bug #52731 [NEW]: mb_strpos reports needle position incorrectly
From: Operating system: PHP version: 5.3SVN-2010-08-29 (snap) Package: mbstring related Bug Type: Bug Bug description:mb_strpos reports needle position incorrectly Description: If code sets incorrect character set (utf-8 instead of big5 in test case), mb_strpos() can incorrectly report needle position in some cases. It looks like $offset is calculated one way and results are calculated in some other way. See test code. mb_substr($str,$pos1,1,'utf-8') can be used to see character that is in reported needle position. I understand that $str is not in UTF-8 charset, but position reported by mb_strpos() violates very basic strpos function behavior. Search is started after $offset position and result position is counted from string start. Result should not be lower than $offset or it should be boolean false. php5.3-201008291230 compiled with /configure --prefix=/somepath --enable-cli --disable-all --enable-mbstring Also tested PHP 5.2.0 (debian etch), 5.3.2-2 (debian squeeze) and 5.2.13 (standard PHP package). 5.2.13 and 5.3.2 results are the same. 5.2.0 results are a little bit different, but I was able to reproduce position calculation problem with more complex code. Test script: --- $str = "\xb7\x51 &\xb4\xa6\xb6\x7d"; $pos1 = mb_strpos($str,'&',0,'utf-8'); var_dump($pos1); $pos2 = mb_strpos($str,'&',$pos1 + 1,'utf-8'); var_dump($pos2); Expected result: second var_dump() result should be higher than first one or should be boolean false. result should not be lower than offset. Actual result: -- int(2) int(2) -- Edit bug report at http://bugs.php.net/bug.php?id=52731&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52731&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52731&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52731&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52731&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52731&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52731&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52731&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52731&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52731&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52731&r=support Expected behavior: http://bugs.php.net/fix.php?id=52731&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52731&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52731&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52731&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52731&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52731&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52731&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52731&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52731&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52731&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52731&r=mysqlcfg
Bug #52730 [Opn]: Impossible to implement Interfaces with same method names
Edit report at http://bugs.php.net/bug.php?id=52730&edit=1
ID: 52730
User updated by:wrzasq at gmail dot com
Reported by:wrzasq at gmail dot com
Summary:Impossible to implement Interfaces with same method
names
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Debian
PHP Version:5.3.3
Block user comment: N
New Comment:
Sorry, a little misstake - of course classes B in case two and three
extend classes A.
Previous Comments:
[2010-08-29 13:02:13] wrzasq at gmail dot com
Description:
It's impossible to implement interfaces with same method names. Whath's
the most strange is, that you can simply "hack" this by implementing
each interface at different inheritance level.
(it's in fact PHP 5.3.2 issue, but I didn't see it fixed in PHP 5.3.3)
Test script:
---
first case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo, Bar
{
public function getID()
{
return 1;
}
}
second case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
}
third case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
public function getID()
{
return parent::getID();
}
}
Expected result:
Nothing at output, but all of them compile.
Actual result:
--
first case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
second case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
third case: worked fine
--
Edit this bug report at http://bugs.php.net/bug.php?id=52730&edit=1
Bug #52720 [Opn->Fbk]: User Session handler Crash [FPM and APC]
Edit report at http://bugs.php.net/bug.php?id=52720&edit=1 ID: 52720 Updated by: johan...@php.net Reported by:mat999 at gmail dot com Summary:User Session handler Crash [FPM and APC] -Status: Open +Status: Feedback Type: Bug Package:Session related Operating System: Debian Lenny Linux PHP Version:5.3.3 Block user comment: N New Comment: I'd also suggest using our sources. We have no control over patches by dotdeb developers and don't know them Previous Comments: [2010-08-28 16:53:40] mat999 at gmail dot com Ok then, dont get precise. Ill have to setup a dev install then on my local PC since I cant do this on my production server. Ill be away tomorow/today (its 1am) so Ill have to do it on monday unless someone test the above code on php-fpm before then. [2010-08-28 16:48:28] ras...@php.net Those are processes, not threads. There is a root-owned master process that preforks multiple child processes to handle requests. Simple set that to a low number in your config file and attach gdb to one of the children. It's easy. [2010-08-28 16:45:51] mat999 at gmail dot com ummm? Yes it is. |-php5-fpm(53652)-+-php5-fpm(21570,www-data) | |-php5-fpm(22058,www-data) | |-php5-fpm(22305,vu2001) | |-php5-fpm(22307,vu2001) | |-php5-fpm(22308,vu2001) | |-php5-fpm(22311,vu2001) | |-php5-fpm(22313,vu2001) | |-php5-fpm(22315,vu2001) | |-php5-fpm(22317,vu2001) | |-php5-fpm(22318,vu2001) | |-php5-fpm(22319,vu2001) | |-php5-fpm(22326,vu2001) | |-php5-fpm(22327,vu2001) | |-php5-fpm(22328,vu2001) | |-php5-fpm(22330,vu2001) | |-php5-fpm(22354,vu2009) | |-php5-fpm(22356,vu2009) | |-php5-fpm(22362,vu2009) | `-php5-fpm(22381,vu2009) [2010-08-28 16:43:52] ras...@php.net No it isn't. [2010-08-28 16:42:18] mat999 at gmail dot com ive tried that but it doesnt propagate to child processes and php-fpm is multy threaded. 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 http://bugs.php.net/bug.php?id=52720 -- Edit this bug report at http://bugs.php.net/bug.php?id=52720&edit=1
Bug #52728 [Opn->Fbk]: realpath() fails to resolve symbolic links (symlinks) in remote file systems
Edit report at http://bugs.php.net/bug.php?id=52728&edit=1
ID: 52728
Updated by: paj...@php.net
Reported by:resonantmedia at gmail dot com
Summary:realpath() fails to resolve symbolic links
(symlinks) in remote file systems
-Status: Open
+Status: Feedback
Type: Bug
Package:Directory function related
Operating System: Ubuntu LTS 8.04
PHP Version:5.2.14
Block user comment: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-08-29 10:18:08] resonantmedia at gmail dot com
Description:
php 5.2.4-2ubuntu5.7
Assuming a symbolic link refers to a script and both are on a remote
file system:
Calling realpath('./') does not produce the same results as
realpath(dirname(__FILENAME__)) when the script is being referred to by
its
symlink over NFS.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52728&edit=1
Bug #52706 [Com]: __sleep inhertiance
Edit report at http://bugs.php.net/bug.php?id=52706&edit=1
ID: 52706
Comment by: dev dot php at linke-t dot net
Reported by:dev dot php at linke-t dot net
Summary:__sleep inhertiance
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.3.3
Block user comment: N
New Comment:
I think the primary problems i have are not tested.
I wrote a class with a private property.
class foo{
private $v;
function foo(){
$this->v="bar";
}
}
And a class wich extends it:
class foo2 extends foo{
function foo2(){
$this->foo();
}
function __sleep(){
return array("v");
}
}
with __sleep serialize will Output: O:10:"foo2":1:{s:1:"v";N;}
without __sleep is the output like:
O:10:"foo2":1:{s:6:"foov";s:3:"bar";}
so serialize without __sleep allow acces to private properties. I think,
if foo2 doesnt have access to a private property of class foo, than
serialize didnt had it too.
But if i want to save an object ... so i need to save it completly ...
so it have to save the private propertys as well. In C++ for as an
example i will copy the memory ... so i have copied the private
properties as all others.
and if this isnt a bug ... it's an bad feature ... I think we need to
call it "The dont use __sleep()" feature ;)
I hope i wont get another "its not a bug" - correct the behaivor or
wrote in the documention how to save an object with private property of
super class, thanks.
"Yes, class design has to be well thought."
Yes, I aggree - and i think the behavior of functions should it be too.
Previous Comments:
[2010-08-26 15:55:50] johan...@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
Yes, class design has to be well thought.
[2010-08-26 12:14:10] dev dot php at linke-t dot net
Description:
i the case of class "B" extends a class "A" wich define the function
__sleep(), instances of class "B" would class A::__sleep. In this case
class serialzing would be very buggy - i tried something like:
Try: let return the __sleep of class "A" all propertys wich are
currently definied
resoulting Problem: private properety of class "B" are null or NAN
Try: define the function __sleep() in class "B"
resoulting Problem: private properety of class "A" are null or NAN
Test script:
---
class A{
public $A_A = 10;
protected $A_B = 11;
private $A_C = 12;
public function A(){
}
private function __sleep(){
echo "sleep of A()";
if(get_class($this) != "A")
{
$d = array_keys( get_class_vars(get_class($this)));
return ($d);
}
return array("A_A","A_B","A_C");
}
public function __get($v){
return "PR";
}
}
class B extends A{
public $B_A = 20;
protected $B_B = 21;
private $B_C = 22;
public function B(){
$this->A();
}
public function __sleep(){
return array("A_A","A_B","A_C","B_A","B_B","B_C");
} /* remove this __sleep would let php use A::__sleep()
}
$a = new A();
$b = new B();
echo "A";
echo "" . htmlspecialchars(serialize($a));
echo "B";
echo "" . htmlspecialchars(serialize($b));
Expected result:
the complettely serialized Object like with out __sleep()!
Actual result:
--
private propertys of parent or child are null or NAN with defined
__sleep()
--
Edit this bug report at http://bugs.php.net/bug.php?id=52706&edit=1
[PHP-BUG] Bug #52730 [NEW]: Impossible to implement Interfaces with same method names
From:
Operating system: Debian
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Impossible to implement Interfaces with same method names
Description:
It's impossible to implement interfaces with same method names. Whath's the
most strange is, that you can simply "hack" this by implementing each
interface at different inheritance level.
(it's in fact PHP 5.3.2 issue, but I didn't see it fixed in PHP 5.3.3)
Test script:
---
first case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo, Bar
{
public function getID()
{
return 1;
}
}
second case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
}
third case:
--
interface Foo
{
public function getID();
}
interface Bar
{
public function getID();
}
class A implements Foo
{
public function getID()
{
return 1;
}
}
class B implements Bar
{
public function getID()
{
return parent::getID();
}
}
Expected result:
Nothing at output, but all of them compile.
Actual result:
--
first case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
second case: Fatal error: Can't inherit abstract function Bar::getID()
(previously declared abstract in Foo) in Command line code on line 1
third case: worked fine
--
Edit bug report at http://bugs.php.net/bug.php?id=52730&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52730&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52730&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52730&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52730&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52730&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52730&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52730&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52730&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52730&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52730&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52730&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52730&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52730&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52730&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52730&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52730&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52730&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52730&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52730&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52730&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52730&r=mysqlcfg
[PHP-BUG] Bug #52729 [NEW]: unpack() format I, L, N and V returns negative value
From:
Operating system: Linux
PHP version: 5.3.3
Package: Unknown/Other Function
Bug Type: Bug
Bug description:unpack() format I, L, N and V returns negative value
Description:
According to the documentation, all I, L, N and V formats are defined to be
unsigned integer. On my Linux(32bit intel), unpacking FF returns -1. As
you
can see the test script, we automatically use float for large integer. So
the
result should be float(4294967295), otherwise we get wrong number of -1.
Test script:
---
float(4294967295)
}
array(1) {
[1]=>
float(4294967295)
}
array(1) {
[1]=>
float(4294967295)
}
array(1) {
[1]=>
float(4294967295)
}
int(2147483647)
int(4)
float(4294967295)
Actual result:
--
array(1) {
[1]=>
int(-1)
}
array(1) {
[1]=>
int(-1)
}
array(1) {
[1]=>
int(-1)
}
array(1) {
[1]=>
int(-1)
}
int(2147483647)
int(4)
float(4294967295)
--
Edit bug report at http://bugs.php.net/bug.php?id=52729&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52729&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52729&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52729&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52729&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52729&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52729&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52729&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52729&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52729&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52729&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52729&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52729&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52729&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52729&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52729&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52729&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52729&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52729&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52729&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52729&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52729&r=mysqlcfg
[PHP-BUG] Bug #52728 [NEW]: realpath() fails to resolve symbolic links (symlinks) in remote file systems
From:
Operating system: Ubuntu LTS 8.04
PHP version: 5.2.14
Package: Directory function related
Bug Type: Bug
Bug description:realpath() fails to resolve symbolic links (symlinks) in remote
file systems
Description:
php 5.2.4-2ubuntu5.7
Assuming a symbolic link refers to a script and both are on a remote file
system:
Calling realpath('./') does not produce the same results as
realpath(dirname(__FILENAME__)) when the script is being referred to by its
symlink over NFS.
--
Edit bug report at http://bugs.php.net/bug.php?id=52728&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52728&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52728&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52728&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52728&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52728&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52728&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52728&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52728&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52728&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52728&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52728&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52728&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52728&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52728&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52728&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52728&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52728&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52728&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52728&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52728&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52728&r=mysqlcfg
