Bug #60431 [Com]: private Array
Edit report at https://bugs.php.net/bug.php?id=60431&edit=1
ID: 60431
Comment by: kapsonfire at gmx dot de
Reported by:kapsonfire at gmx dot de
Summary:private Array
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Debian Squeeze
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The problem is that private vars shouldn't be readable for security reasons.
Even in debugging purposes
if you create an instance of a class on $owner, which is private
it isn`t readable with print_r
of course, using $class->attribut doesn't work
but private variables should never readable outside of the class
if they are still readable with debugging methods it's still a security leak
for me
and i don't believe its expected to be readable, because then there should be
all private variables be readable via print_r
Previous Comments:
[2011-12-02 12:22:26] paj...@php.net
No, it is not readable. Using:
class Item {
private $DATA=array();
private $OWNER=null;
public function __construct($itemID) {
}
}
$a = new Item(1);
$a->DATA;
PHP Fatal error: Cannot access private property Item::$DATA in
/home/pierre/60431.php on line 14
[2011-12-02 12:15:11] kapsonfire at gmx dot de
Well, but this only happens with arrays used as datalayer in this way.
The $OWNER isn't readable outside with print_r after creating an instance on it.
[2011-12-02 12:11:33] paj...@php.net
Release\php.exe -n -r "class f {private $f=1;} $a = new f; $a->f;"
Fatal error: Cannot access private property f::$f in Command line code on line 1
print_r/var_dump are only a debugging/informative functions.
[2011-12-02 12:03:45] kapsonfire at gmx dot de
Description:
Using an private array in a Class as Data Layer become readale outside of class
with print_r
Test script:
---
ITEMOBJECT:".(print_r($item,true))."";
?>
DATA[$key] = $item[$key];
}
}
}
Expected result:
ITEMOBJECT:
Item Object
(
[DATA:Item:private] => Array
(
[itemid] => 1
[uid] => 2
)
[OWNER:Item:private] =>
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60431&edit=1
Req #46705 [Com]: Impossible to implement compatible interfaces
Edit report at https://bugs.php.net/bug.php?id=46705&edit=1
ID: 46705
Comment by: clicky at erebot dot net
Reported by:wrzasq at gmail dot com
Summary:Impossible to implement compatible interfaces
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Debian GNU/Linux
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
I was unable to reproduce the fatal errors from my initial testcases with PHP
5.4.0RC2:
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B { public
function foo(); } class Foo implements A,B { public function foo() {} }; $foo =
new Foo;'
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B extends A {
public function foo(); } class Foo implements B { public function foo() {} };
$foo = new Foo;'
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B extends A {
public function foo($bar=null); } class Foo implements B { public function
foo($bar=null) {} }; $foo = new Foo;'
All those pass (don't raise any fatal error).
So I guess the patch for #43200 that landed in 5.4.0RC2 also fixed this issue.
Previous Comments:
[2011-11-28 20:07:40] clicky at erebot dot net
tklingenberg at lastflood dot net:
I think you missed the point, or to rephrase it another way: the problem lies
in the definition of "compatible":
and
should both be considered valid scripts because the two signatures for foo()
[in interface A and interface B] do not contradict each other: it is possible
to write a method that satisfies both.
The same argument also holds for the example smith gave:
Now, imagine that I want to create a Humanoid class (a mix between a Person and
a Robot). Quite naturally, I'd want to write something like this:
goForward(1); }
public function roll() { $this->goForward(3); }
// some other methods...
}
?>
Unfortunately, this will give you an error such as this:
"PHP Fatal error: Can't inherit abstract function Robot::speak() (previously
declared abstract in Person) in Command line code on line 1"
... and that's what this bug is all about...
It's a PITA when you must work with interfaces defined by other people which
are compatible (ex: both force you to define a "__toString" method) and yet PHP
returns a fatal error when you try to use them in your own class.
[2011-11-27 18:03:02] tklingenberg at lastflood dot net
Actually it's possible, you just need to make the interfaces compatible for
that:
interface A
{
public function foo();
}
interface B extends A
{
}
and then you're done. This also prevents you from writing duplicate code ;)
However if interfaces definitions can not be changed, then this is not a
solution. Probably this is fixed? - See bug #43200.
[2011-08-01 12:11:11] smith at pooteeweet dot org
Note its also not possible to redefine while adding new optional parameters
ding('yeah!');
[2011-03-22 23:33:03] clicky at erebot dot net
I think this use case, the one bug #43200 and the one below are all valid:
The case above may seem odd (there's really no point in redefining the exact
same interface), but I have a simple use case where this may prove handy.
I'm currently writing some code for a little project which is meant to teach
some middle to advanced topics of PHP. The code is self-documented (using
doxygen) and uses some interface from SPL (Countable). That interface is used
several times in different files and I'd like to document the count() method
only once (if possible, at the interface level -- then using doxygen's ability
to copy/paste the doc from parent classes/interfaces into the current class).
I thought I could just define my own interface (Project_Countable), extending
from SPL's Countable, "overriding" the method's signature (only so doxygen can
pick up the method's declaration -- the prototype for the method was actually
left unchanged) and then define a class that implements Project_Countable.
So in my case, A = SPL's Countable interface and B = Project_Countable.
However, this pattern can't be used as it results in the same error others
noted here and in bug #43200.
I can't simply avoid Project_Countable extending from Countable, because then I
would lose count()'s "magic" by doing so.
[2008-11-28 07:57:42] wrzasq at gmail dot com
Description:
It is impossible to implement multiple interfaces that declares same
methods. I saw bug #43200 but this is a bit different case and I
think in this situation it shoud be allowed - those int
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: sg at facelift-bbt dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug was first reported 9 years ago? This definetly got to be fixed. This is a total stopper. I can reproduce it exactly it is shown below. Previous Comments: [2011-11-06 19:29:44] gerd dot katzenbeisser at gmail dot com here is a simple test case using the internal class PharFileInfo Output: Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false [2011-09-16 14:18:21] robin dot bussiek at googlemail dot com @sweiss-at-stylesight thanks for your explanation. Big +1 for any solution to this topic. [2011-09-15 19:59:27] sweiss at stylesight dot com No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. [2011-09-15 19:51:48] robin dot bussiek at googlemail dot com I am sorry to ask this for my understanding: Is it true, that the cause for this bug lies in a false inclusion of the "I" character in the Turkish character set - and therefore results in an unnecessary replacement? If so, my green knowledge leads me to the assumption, that a fix should be rather simple. **duck**, Robin [2011-08-08 12:02:30] tolga at profelis dot com dot tr php -v PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40) Problem continues! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
Req #46705 [Opn->Csd]: Impossible to implement compatible interfaces
Edit report at https://bugs.php.net/bug.php?id=46705&edit=1
ID: 46705
Updated by: fel...@php.net
Reported by:wrzasq at gmail dot com
Summary:Impossible to implement compatible interfaces
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Debian GNU/Linux
PHP Version:5.2.6
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Yes, it fixes this issue. Thanks for testing. :)
Previous Comments:
[2011-12-03 17:47:17] clicky at erebot dot net
I was unable to reproduce the fatal errors from my initial testcases with PHP
5.4.0RC2:
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B { public
function foo(); } class Foo implements A,B { public function foo() {} }; $foo =
new Foo;'
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B extends A {
public function foo(); } class Foo implements B { public function foo() {} };
$foo = new Foo;'
php-5.4.0RC2 -r 'interface A { public function foo(); } interface B extends A {
public function foo($bar=null); } class Foo implements B { public function
foo($bar=null) {} }; $foo = new Foo;'
All those pass (don't raise any fatal error).
So I guess the patch for #43200 that landed in 5.4.0RC2 also fixed this issue.
[2011-11-28 20:07:40] clicky at erebot dot net
tklingenberg at lastflood dot net:
I think you missed the point, or to rephrase it another way: the problem lies
in the definition of "compatible":
and
should both be considered valid scripts because the two signatures for foo()
[in interface A and interface B] do not contradict each other: it is possible
to write a method that satisfies both.
The same argument also holds for the example smith gave:
Now, imagine that I want to create a Humanoid class (a mix between a Person and
a Robot). Quite naturally, I'd want to write something like this:
goForward(1); }
public function roll() { $this->goForward(3); }
// some other methods...
}
?>
Unfortunately, this will give you an error such as this:
"PHP Fatal error: Can't inherit abstract function Robot::speak() (previously
declared abstract in Person) in Command line code on line 1"
... and that's what this bug is all about...
It's a PITA when you must work with interfaces defined by other people which
are compatible (ex: both force you to define a "__toString" method) and yet PHP
returns a fatal error when you try to use them in your own class.
[2011-11-27 18:03:02] tklingenberg at lastflood dot net
Actually it's possible, you just need to make the interfaces compatible for
that:
interface A
{
public function foo();
}
interface B extends A
{
}
and then you're done. This also prevents you from writing duplicate code ;)
However if interfaces definitions can not be changed, then this is not a
solution. Probably this is fixed? - See bug #43200.
[2011-08-01 12:11:11] smith at pooteeweet dot org
Note its also not possible to redefine while adding new optional parameters
ding('yeah!');
[2011-03-22 23:33:03] clicky at erebot dot net
I think this use case, the one bug #43200 and the one below are all valid:
The case above may seem odd (there's really no point in redefining the exact
same interface), but I have a simple use case where this may prove handy.
I'm currently writing some code for a little project which is meant to teach
some middle to advanced topics of PHP. The code is self-documented (using
doxygen) and uses some interface from SPL (Countable). That interface is used
several times in different files and I'd like to document the count() method
only once (if possible, at the interface level -- then using doxygen's ability
to copy/paste the doc from parent classes/interfaces into the current class).
I thought I could just define my own interface (Project_Countable), extending
from SPL's Countable, "overriding" the method's signature (only so doxygen can
pick up the method's declaration -- the prototype for the method was actually
left unchanged) and then define a class that implements Project_Countable.
So in my case, A = SPL's Countable interface and B = Project_Countable.
However, this pattern can't be used as it results in the same error others
noted here and in bug #43200.
I can't simply avoid Project_Countable extending from Countable, because then I
would lose count()'s "magic" by doing so.
The remainder of the co
Doc->Req #55822 [Opn]: elseif/else if opcode difference
Edit report at https://bugs.php.net/bug.php?id=55822&edit=1 ID: 55822 Updated by: frozenf...@php.net Reported by:jhansche at myyearbook dot com Summary:elseif/else if opcode difference Status: Open -Type: Documentation Problem +Type: Feature/Change Request -Package:Documentation problem +Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: @derick: I agree that it would probably be sensible for PHP to conjoin else if into elseif, where it sees that opcode combination. I'll change the bug to that. Previous Comments: [2011-10-09 09:59:21] der...@php.net @frozenfire: No need to open a bug (he already did that AFAIK), because it's not something in Xdebug that I can do anything about (as the opcodes are generated by PHP). It doesn't belong in PHP's docs though, but perhaps we can see whether we can change PHP itself to make this look similar. [2011-10-08 21:35:36] frozenf...@php.net I feel that discussion of the opcode is beyond the scope of that document. It's a very esoteric distinction, which would only serve to confuse, rather than to educate. It would probably be a better idea to document this in XDebug or PHPUnit's manual, rather than PHP's. For the purposes of the execution of the code, this distinction is irrelevant. Though, better yet, it might be worth opening a bug for XDebug, indicating that this trivial opcode distinction is impairing the ability to get proper code coverage. [2011-09-30 16:42:57] jhansche at myyearbook dot com Description: --- >From manual page: http://www.php.net/control-structures.elseif --- It is worth explaining the difference in opcode generation using "elseif" vs "else if" -- or at least the effect of using one over the other. Specifically, I'm referring to using PHPUnit with XDebug, in order to get code coverage for some code. What I've noticed is that using "else if", even if you fully test that branch, no code coverage is produced for that condition line (the code coverage report just skips over the "else if .." line, leaving one line unexecuted, while everything else is green). Replacing that line with "elseif" instead, produces full green code coverage! See the test script below, and the output from using vld (http://pecl.php.net/package/vld) to show the difference in opcode generation, wherein having the space between "else" and "if" causes the opcode to report the wrong line number, and therefore something like xdebug, which tracks what lines get executed, is unable to track the fact that the line was executed, and there is no code coverage. The difference between "elseif" and "else if" should not cause unit testing code coverage reports to change behavior. The only way to get proper code coverage with this bug is to force the developer to use "elseif". Test script and results can also be seen at: https://php.privatepaste.com/f468504857 Test script: --- space.php: nospace.php: space.vld $ php -dvld.active=1 nospace.php >nospace.vld $ diff -uN space.vld nospace.vld -- Edit this bug report at https://bugs.php.net/bug.php?id=55822&edit=1
[PHP-BUG] Bug #60439 [NEW]: curl_copy_handle segfault when used with CURLOPT_PROGRESSFUNCTION
From:
Operating system: Any
PHP version: 5.3.8
Package: cURL related
Bug Type: Bug
Bug description:curl_copy_handle segfault when used with
CURLOPT_PROGRESSFUNCTION
Description:
The curl_copy_handle function don't work when used with
CURLOPT_PROGRESSFUNCTION
Test script:
---
http://www.php.net');
curl_setopt($ch, CURLOPT_NOPROGRESS, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_PROGRESSFUNCTION, function() { });
$ch2 = curl_copy_handle($ch);
echo curl_exec($ch);
unset($ch);
echo curl_exec($ch2);
Expected result:
No segault
Actual result:
--
Segfault
--
Edit bug report at https://bugs.php.net/bug.php?id=60439&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60439&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60439&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60439&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60439&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60439&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60439&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60439&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60439&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60439&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60439&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60439&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60439&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60439&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60439&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60439&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60439&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60439&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60439&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60439&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60439&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60439&r=mysqlcfg
Bug #60439 [Opn->Csd]: curl_copy_handle segfault when used with CURLOPT_PROGRESSFUNCTION
Edit report at https://bugs.php.net/bug.php?id=60439&edit=1
ID: 60439
Updated by: pierr...@php.net
Reported by:pierr...@php.net
Summary:curl_copy_handle segfault when used with
CURLOPT_PROGRESSFUNCTION
-Status: Open
+Status: Closed
Type: Bug
Package:cURL related
Operating System: Any
PHP Version:5.3.8
-Assigned To:
+Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-12-04 01:34:37] pierr...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=320341
Log: Fixed bug #60439curl_copy_handle segfault when used with
CURLOPT_PROGRESSFUNCTION
[2011-12-04 01:30:06] pierr...@php.net
Description:
The curl_copy_handle function don't work when used with CURLOPT_PROGRESSFUNCTION
Test script:
---
http://www.php.net');
curl_setopt($ch, CURLOPT_NOPROGRESS, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_PROGRESSFUNCTION, function() { });
$ch2 = curl_copy_handle($ch);
echo curl_exec($ch);
unset($ch);
echo curl_exec($ch2);
Expected result:
No segault
Actual result:
--
Segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=60439&edit=1
Req #54022 [Asn->Csd]: Add support for curl_easy_reset
Edit report at https://bugs.php.net/bug.php?id=54022&edit=1 ID: 54022 Updated by: pierr...@php.net Reported by:mtdowling at gmail dot com Summary:Add support for curl_easy_reset -Status: Assigned +Status: Closed Type: Feature/Change Request Package:cURL related Operating System: Mac OS X PHP Version:5.3.5 Assigned To:pierrick Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Committed to trunk :) Previous Comments: [2011-11-23 07:55:27] pierr...@php.net The provided patch is not valid. All the handlers of the php_curl_handlers structure also need to be reseted. [2011-08-19 20:17:08] mtdowling at gmail dot com Any news on this? I submitted a patch and announced it on the mailing list. Please let me know if you need anything further from me. [2011-02-15 04:57:36] mtdowling at gmail dot com Description: It's difficult to use the same curl handle for multiple requests to the same host and port when many unknown options could have been applied to the handle after its creation. Many of the curl_setopt options can be removed from a handle using some careful option setting, but some options cannot. Adding a curl_easy_reset method to the PHP bindings would allow PHP developers to more easily implement connection pooling and utilize keep-alive sessions over HTTP/1.1. curl_easy_reset has been available since version 7.12.1 (http://curl.haxx.se/libcurl/c/curl_easy_reset.html): Re-initializes all options previously set on a specified CURL handle to the default values. This puts back the handle to the same state as it was in when it was just created with curl_easy_init(3). It does not change the following information kept in the handle: live connections, the Session ID cache, the DNS cache, the cookies and shares. -- Edit this bug report at https://bugs.php.net/bug.php?id=54022&edit=1
Bug #38805 [Opn->]: PDO Truncates Text from SQL Server Text Data Type Field
Edit report at https://bugs.php.net/bug.php?id=38805&edit=1
ID: 38805
Updated by: ssuffic...@php.net
Reported by:gkrajci at arescorporation dot com
Summary:PDO Truncates Text from SQL Server Text Data Type
Field
-Status: Open
+Status: To be documented
Type: Bug
Package:PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version:5.1.6
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-12-17 21:07:48] ka...@php.net
.
[2010-03-04 20:55:06] juan dot pineda at resultstel dot com
I solved this problem by adding to my php script a TEXTSIZE that is less than
the allowed memory from the MSSQL server.
Remember, all the number are in Bytes, so I kept playing with the numbers,
until this worked:
// ranges from 0 - 3145728 = 3Megabytes. Default to 4096.
$sql = "SET TEXTSIZE 3145728";
mssql_query($sql, $db) or die(mssql_get_last_message());
Remember to always know what the allowed upload size for your server is.
I hope this helps someone
[2010-02-12 16:57:02] s...@php.net
Those changes are still in SVN. That means the TEXTLIMIT var is being set to
its highest possible value, which in turn means that truncation shouldn't be an
issue now.
$pdo->query('SET TEXTSIZE 30');
should work from PHP 5.2.11 up, it just needs doccing.
[2010-02-12 09:05:28] philipp at servicemail24 dot de
This problem is actually fixed in cvs:
http://www.mail-archive.com/php-cvs@lists.php.net/msg40731.html
http://www.mail-archive.com/php-cvs@lists.php.net/msg40711.html
Here is the working source code:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_dblib/
I have no idea why these fixes aren't included in the 5.2 and 5.3 releases!
@sfox can you ensure that pdo_dblib is updated with the release of 5.2.13 and
5.3.2?
[2010-02-11 15:40:43] philipp at servicemail24 dot de
php 5.3.2 dotdeb still suffers from this problem.
does this fix help?
"Possible fix: remove "case SQLTEXT" from
ext/pdo_dblib/dblib_stmt.c:execute and let it fall though to default."
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=38805
--
Edit this bug report at https://bugs.php.net/bug.php?id=38805&edit=1
