Req #63366 [Opn]: Number format in error-log-file
Edit report at https://bugs.php.net/bug.php?id=63366&edit=1 ID: 63366 Updated by: larue...@php.net Reported by:p dot varga at lottery24 dot net Summary:Number format in error-log-file Status: Open Type: Feature/Change Request Package:Output Control Operating System: Linux Suse Server PHP Version:5.4.7RC1 Block user comment: N Private report: N New Comment: dup to #63354 Previous Comments: [2012-10-26 06:54:54] p dot varga at lottery24 dot net Description: The displayed numbers in the PHP error log files are not easy to read: When displaying this error message it takes seconds until the correct number is read: Allowed memory size of 13000 bytes exhausted (tried to allocate 13361 bytes) Test script: --- Expected result: Allowed memory size of 130.000.000 bytes exhausted (tried to allocate 133.600.001 bytes) -- Edit this bug report at https://bugs.php.net/bug.php?id=63366&edit=1
Req #63366 [Opn->Dup]: Number format in error-log-file
Edit report at https://bugs.php.net/bug.php?id=63366&edit=1 ID: 63366 Updated by: larue...@php.net Reported by:p dot varga at lottery24 dot net Summary:Number format in error-log-file -Status: Open +Status: Duplicate Type: Feature/Change Request Package:Output Control Operating System: Linux Suse Server PHP Version:5.4.7RC1 Block user comment: N Private report: N Previous Comments: [2012-10-26 07:23:55] larue...@php.net dup to #63354 [2012-10-26 06:54:54] p dot varga at lottery24 dot net Description: The displayed numbers in the PHP error log files are not easy to read: When displaying this error message it takes seconds until the correct number is read: Allowed memory size of 13000 bytes exhausted (tried to allocate 13361 bytes) Test script: --- Expected result: Allowed memory size of 130.000.000 bytes exhausted (tried to allocate 133.600.001 bytes) -- Edit this bug report at https://bugs.php.net/bug.php?id=63366&edit=1
Req #44369 [Com]: PHP Loop Labels
Edit report at https://bugs.php.net/bug.php?id=44369&edit=1
ID: 44369
Comment by: root at bugs dot php dot net
Reported by:php at xyzzy dot cjb dot net
Summary:PHP Loop Labels
Status: Not a bug
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Mac OS X 10.5.2
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Did you consider this:
for ($i = 0; $i < 5; ++$i)
{
print "$i: ";
for ($j = 0; $j < 5; ++$j)
{
print "$j ";
if ($j == 2 && $i == 4)
goto END;
}
print "\n";
END:
}
If the label needs to proceed a statement, try LABEL: noop();
Another solution could be to get the the nesting level and use:
continue $nest_level - 1;
Unfortunately, I can find no such function so this would need to be done
manually.
Previous Comments:
[2008-03-08 18:16:11] php at xyzzy dot cjb dot net
How can this code be rewritten using goto? I downloaded a PHP 6 snapshot and
tried this:
ROW: for ($i = 0; $i < 5; ++$i)
{
print "$i: ";
COLUMN: for ($j = 0; $j < 5; ++$j)
{
print "$j ";
if ($j == 2 && $i == 4)
goto ROW;
}
print "\n";
}
but the entire loop is repeated; it doesn't produce the same output as the
first example.
>From http://www.php.net/~derick/meeting-notes.html#adding-goto (first result
>on Google for "php 6 goto"), I see that there were plans to "reuse the break
>keyword, and extend it with a static label.", but this does not appear to be
>implemented the the latest snapshot. Those meeting notes were from 2005
>however. Google also found http://php6dev.blogspot.com/ but that page is
>currently down so I couldn't read it.
How can I use goto to act as "continue 2" or "break 2"? I also tried:
for ($i = 0; $i < 5; ROW: ++$i)
{
print "$i: ";
for ($j = 0; $j < 5; ++$j)
{
print "$j ";
if ($j == 2 && $i == 4)
goto ROW;
}
print "\n";
}
and: for ($i = 0; ROW: $i < 5; ++$i)
and: for (ROW: $i = 0; $i < 5; ROW: ++$i)
but these all report:
Parse error: syntax error, unexpected ':', expecting ')'
[2008-03-08 11:41:48] johan...@php.net
PHP 6 has goto which can be used for that.
[2008-03-08 06:56:00] php at xyzzy dot cjb dot net
Description:
This is an enhancement request to add loop labels to PHP. Currently, to
break out of nested loops, PHP allows you to specify a number to a break
or continue statement. It would increase code clarity and
maintainability to be able to specify a textual label of the loop to
continue or break out of.
This is similar to Bug #29287 "Request: Line labels and goto" except
that I'm not requesting goto, which is what that bug was mostly used to
discuss before being closed. This ticket is specifically for the feature
of adding loop labels, which was not adequately discussed in #29287.
Reproduce code:
---
An example of a nested loop (admittedly not a very useful example), how PHP
currently allows you to write it:
for ($i = 0; $i < 5; ++$i)
{
print "$i: ";
for ($j = 0; $j < 5; ++$j)
{
print "$j ";
if ($j == 2 && $i == 4)
continue 2;
}
print "\n";
}
How I would like to be able to write it:
ROW: for ($i = 0; $i < 5; ++$i)
{
print "$i: ";
COLUMN: for ($j = 0; $j < 5; ++$j)
{
print "$j ";
if ($j == 2 && $i == 4)
continue ROW;
}
print "\n";
}
Expected result:
Both examples should behave the same, if this feature is implemented.
Actual result:
--
Parse error: syntax error, unexpected ':' in /private/tmp/a.php on line
2
--
Edit this bug report at https://bugs.php.net/bug.php?id=44369&edit=1
Bug #62707 [Asn]: nextRowset causes segfault when using libmysql
Edit report at https://bugs.php.net/bug.php?id=62707&edit=1
ID: 62707
Updated by: u...@php.net
Reported by:keithm at aoeex dot com
Summary:nextRowset causes segfault when using libmysql
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Here's a proper test:
--TEST--
Bug #62707 (nextRowset causes segfault when using libmysql)
--SKIPIF--
query('SELECT VERSION() as _version')->fetch(PDO::FETCH_ASSOC);
$matches = array();
if (!preg_match('/^(\d+)\.(\d+)\.(\d+)/ismU', $row['_version'], $matches))
die(sprintf("skip Cannot determine MySQL Server version\n"));
$version = $matches[0] * 1 + $matches[1] * 100 + $matches[2];
if ($version < 5)
die(sprintf("skip Need MySQL Server 5.0.0+, found %d.%02d.%02d (%d)\n",
$matches[0], $matches[1], $matches[2], $version));
?>
--FILE--
setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->exec('DROP PROCEDURE IF EXISTS p');
$db->exec('CREATE PROCEDURE p() BEGIN SELECT 1 AS "one"; SET @myvar = 1; SELECT
2 AS "two", 3 AS "three"; END');
$stmt = $db->query("CALL p()");
do {
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
} while ($stmt->nextRowset());
var_dump($stmt->errorInfo());
$stmt = $db->query('SELECT 4 AS "four"');
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
var_dump($stmt->errorInfo());
print "done!";
?>
--EXPECTF--
array(1) {
[0]=>
array(1) {
["one"]=>
int(1)
}
}
array(1) {
[0]=>
array(2) {
["two"]=>
int(2)
["three"]=>
int(3)
}
}
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
array(1) {
[0]=>
array(1) {
["four"]=>
int(4)
}
}
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
done!
Previous Comments:
[2012-07-31 19:09:55] keithm at aoeex dot com
Description:
Using PDO with the MySQL driver built using libmysql
pdo_mysql
PDO Driver for MySQL => enabled
Client API version => 5.5.25a
After calling a stored procedure I have the following lines to eat up the
results before running more queries:
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while ($queueStmt-
>nextRowset());
When using libmysql this results in a segfault when calling nextRowset.
Test script:
---
"SET NAMES utf8"));
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sql = 'DROP TABLE IF EXISTS testtbl';
$db->exec($sql);
$sql = 'DROP PROCEDURE IF EXISTS testproc';
$db->exec($sql);
$sql = 'CREATE TABLE testtbl (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, data
VARCHAR(10), nextrun DATETIME)';
$db->exec($sql);
$sql = "INSERT INTO testtbl (data, nextrun) VALUES ('asdf',
UTC_TIMESTAMP()),('defg', UTC_TIMESTAMP()),('higk', UTC_TIMESTAMP()),('lmnop',
UTC_TIMESTAMP())";
$db->exec($sql);
$sql = 'CREATE PROCEDURE testproc() NOT DETERMINISTIC MODIFIES SQL DATA BEGIN
DECLARE nextId INT; SELECT pk INTO nextId FROM testtbl WHERE nextrun=(SELECT
MIN(nextrun) FROM testtbl) LIMIT 1; UPDATE testtbl SET
nextrun=UTC_TIMESTAMP()+INTERVAL 1 DAY WHERE pk=nextId; SELECT * FROM testtbl
WHERE pk=nextId; END';
$db->exec($sql);
$queueSql = 'CALL testproc()';
$queueStmt = $db->prepare($queueSql);
$queueStmt->execute();
$row=$queueStmt->fetch(PDO::FETCH_ASSOC);
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while
($queueStmt->nextRowset());
echo "Success";
Expected result:
Success
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=62707&edit=1
Bug #62707 [Asn]: nextRowset causes segfault when using libmysql
Edit report at https://bugs.php.net/bug.php?id=62707&edit=1
ID: 62707
Updated by: u...@php.net
Reported by:keithm at aoeex dot com
Summary:nextRowset causes segfault when using libmysql
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Your patch will unveil a leak. Workaround: don't use PDO, SP and libmysql. Go
mysqlnd.
Previous Comments:
[2012-10-26 09:27:08] u...@php.net
Here's a proper test:
--TEST--
Bug #62707 (nextRowset causes segfault when using libmysql)
--SKIPIF--
query('SELECT VERSION() as _version')->fetch(PDO::FETCH_ASSOC);
$matches = array();
if (!preg_match('/^(\d+)\.(\d+)\.(\d+)/ismU', $row['_version'], $matches))
die(sprintf("skip Cannot determine MySQL Server version\n"));
$version = $matches[0] * 1 + $matches[1] * 100 + $matches[2];
if ($version < 5)
die(sprintf("skip Need MySQL Server 5.0.0+, found %d.%02d.%02d (%d)\n",
$matches[0], $matches[1], $matches[2], $version));
?>
--FILE--
setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->exec('DROP PROCEDURE IF EXISTS p');
$db->exec('CREATE PROCEDURE p() BEGIN SELECT 1 AS "one"; SET @myvar = 1; SELECT
2 AS "two", 3 AS "three"; END');
$stmt = $db->query("CALL p()");
do {
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
} while ($stmt->nextRowset());
var_dump($stmt->errorInfo());
$stmt = $db->query('SELECT 4 AS "four"');
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
var_dump($stmt->errorInfo());
print "done!";
?>
--EXPECTF--
array(1) {
[0]=>
array(1) {
["one"]=>
int(1)
}
}
array(1) {
[0]=>
array(2) {
["two"]=>
int(2)
["three"]=>
int(3)
}
}
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
array(1) {
[0]=>
array(1) {
["four"]=>
int(4)
}
}
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
done!
[2012-07-31 19:09:55] keithm at aoeex dot com
Description:
Using PDO with the MySQL driver built using libmysql
pdo_mysql
PDO Driver for MySQL => enabled
Client API version => 5.5.25a
After calling a stored procedure I have the following lines to eat up the
results before running more queries:
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while ($queueStmt-
>nextRowset());
When using libmysql this results in a segfault when calling nextRowset.
Test script:
---
"SET NAMES utf8"));
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sql = 'DROP TABLE IF EXISTS testtbl';
$db->exec($sql);
$sql = 'DROP PROCEDURE IF EXISTS testproc';
$db->exec($sql);
$sql = 'CREATE TABLE testtbl (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, data
VARCHAR(10), nextrun DATETIME)';
$db->exec($sql);
$sql = "INSERT INTO testtbl (data, nextrun) VALUES ('asdf',
UTC_TIMESTAMP()),('defg', UTC_TIMESTAMP()),('higk', UTC_TIMESTAMP()),('lmnop',
UTC_TIMESTAMP())";
$db->exec($sql);
$sql = 'CREATE PROCEDURE testproc() NOT DETERMINISTIC MODIFIES SQL DATA BEGIN
DECLARE nextId INT; SELECT pk INTO nextId FROM testtbl WHERE nextrun=(SELECT
MIN(nextrun) FROM testtbl) LIMIT 1; UPDATE testtbl SET
nextrun=UTC_TIMESTAMP()+INTERVAL 1 DAY WHERE pk=nextId; SELECT * FROM testtbl
WHERE pk=nextId; END';
$db->exec($sql);
$queueSql = 'CALL testproc()';
$queueStmt = $db->prepare($queueSql);
$queueStmt->execute();
$row=$queueStmt->fetch(PDO::FETCH_ASSOC);
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while
($queueStmt->nextRowset());
echo "Success";
Expected result:
Success
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=62707&edit=1
[PHP-BUG] Bug #63368 [NEW]: Apache 2.2.15 + mod_fcgid + PHP 5.3.3
From: mega dot venik at gmail dot com Operating system: Centos 6.3 PHP version: 5.3.18 Package: PHP options/info functions Bug Type: Bug Bug description:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 Description: There's a Centos6.3 system. Apache 2.2.15 + mod_fcgid + PHP 5.3.3 There's a problem with date.timezone value. It's mentioned in the global /etc/php.ini like this: date.timezone = "Europe/Moscow" And doesn't mentioned in user's local php.ini. As a result, I'm getting lot's of warnings like: Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead in ... Including the date.timezone parameter into the user's php.ini solves the problem, but I don't think, that it's the best solution. Why PHP doesn't read the timezone value from the global config file? Thanks! -- Edit bug report at https://bugs.php.net/bug.php?id=63368&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63368&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63368&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63368&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63368&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63368&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63368&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63368&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63368&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63368&r=support Expected behavior: https://bugs.php.net/fix.php?id=63368&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63368&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63368&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63368&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63368&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63368&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63368&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63368&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63368&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63368&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63368&r=mysqlcfg
Bug #63368 [Opn]: Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone
Edit report at https://bugs.php.net/bug.php?id=63368&edit=1 ID: 63368 User updated by:mega dot venik at gmail dot com Reported by:mega dot venik at gmail dot com -Summary:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 +Summary:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone Status: Open Type: Bug Package:PHP options/info functions Operating System: Centos 6.3 PHP Version:5.3.18 Block user comment: N Private report: N New Comment: correction Previous Comments: [2012-10-26 11:35:05] mega dot venik at gmail dot com Description: There's a Centos6.3 system. Apache 2.2.15 + mod_fcgid + PHP 5.3.3 There's a problem with date.timezone value. It's mentioned in the global /etc/php.ini like this: date.timezone = "Europe/Moscow" And doesn't mentioned in user's local php.ini. As a result, I'm getting lot's of warnings like: Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead in ... Including the date.timezone parameter into the user's php.ini solves the problem, but I don't think, that it's the best solution. Why PHP doesn't read the timezone value from the global config file? Thanks! -- Edit this bug report at https://bugs.php.net/bug.php?id=63368&edit=1
[PHP-BUG] Bug #63369 [NEW]: (un)serialize() leaves dangling pointers, causes crashes
From: tony2001
Operating system: *
PHP version: 5.4Git-2012-10-26 (Git)
Package: Reproducible crash
Bug Type: Bug
Bug description:(un)serialize() leaves dangling pointers, causes crashes
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize)
and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory
manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes
immediate crash.
The attached scripts demonstrates the problem with serialize() and I'm
kinda lazy to
do the same for unserialize(), especially taking into account that the
patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array("test", "1", 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:"stdclass":0:{}')); //to clear
BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit bug report at https://bugs.php.net/bug.php?id=63369&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63369&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63369&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63369&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63369&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63369&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63369&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63369&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63369&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63369&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63369&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63369&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63369&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63369&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63369&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63369&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63369&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63369&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63369&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63369&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63369&r=mysqlcfg
Bug #63369 [PATCH]: (un)serialize() leaves dangling pointers, causes crashes
Edit report at https://bugs.php.net/bug.php?id=63369&edit=1
ID: 63369
Patch added by: tony2...@php.net
Reported by:tony2...@php.net
Summary:(un)serialize() leaves dangling pointers, causes
crashes
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.4Git-2012-10-26 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369&patch=the-patch&revision=1351254242
Previous Comments:
[2012-10-26 12:23:16] tony2...@php.net
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array("test", "1", 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:"stdclass":0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369&edit=1
Req #41243 [Com]: How to use ZIPARCHIVE::CM_STORE
Edit report at https://bugs.php.net/bug.php?id=41243&edit=1 ID: 41243 Comment by: kalibrov1 at gmail dot com Reported by:joel dot alexandre at gmail dot com Summary:How to use ZIPARCHIVE::CM_STORE Status: Assigned Type: Feature/Change Request Package:Zip Related PHP Version:5.x Assigned To:pajoye Block user comment: N Private report: N New Comment: Faced with the same problem, I can not create the correct ODS file! Previous Comments: [2012-10-17 12:01:39] spamme at filbilisim dot com For back up features and performance issues uncompressed zipping is essential. Please provide this feature [2012-07-18 16:54:16] frozenf...@php.net Any progress on this, pajoye? Given the number of votes on this bug, and its age, I think this needs to be addressed as soon as possible. I encountered this bug today, and it's quite frustrating to not be able to set the compression level. [2012-01-23 10:57:54] mpeters at domblogger dot net It is imperative that this bug be addressed and fixed. The epub specification requires that the first file in the zip archive be named mimetype and be uncompressed. Until this bug is fixed, it is thus impossible to create a valid epub file in pure php w/o executing system commands (forbidden in many environments). *maybe* it could be worked around by having a skeleton zip archive with the mimetype file in it uncompressed, but really, we need to be able to create a fresh zip archive, add that file, with no compression. [2010-07-02 14:20:03] php at atis dot id dot lv This would be quite nice for me too. No compression could be useful for creating large archives of multiple files on the fly. [2010-06-04 17:44:31] shockmaker at hotmail dot com I'm looking to create a zip file with a compression level of 0 on some files. So this feature is essential for me. 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=41243 -- Edit this bug report at https://bugs.php.net/bug.php?id=41243&edit=1
Bug #63369 [Opn->Csd]: (un)serialize() leaves dangling pointers, causes crashes
Edit report at https://bugs.php.net/bug.php?id=63369&edit=1
ID: 63369
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:(un)serialize() leaves dangling pointers, causes
crashes
-Status: Open
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.4Git-2012-10-26 (Git)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f2bffdc2e48174e38a059d425953e8b1c08dd4bf
Log: fix bug #63369
Previous Comments:
[2012-10-26 12:24:03] tony2...@php.net
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369&patch=the-patch&revision=1351254242
[2012-10-26 12:23:16] tony2...@php.net
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array("test", "1", 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:"stdclass":0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369&edit=1
Bug #63369 [Csd]: (un)serialize() leaves dangling pointers, causes crashes
Edit report at https://bugs.php.net/bug.php?id=63369&edit=1
ID: 63369
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:(un)serialize() leaves dangling pointers, causes
crashes
Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.4Git-2012-10-26 (Git)
-Assigned To:
+Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
Merged patches f2bffdc and 01dee2c.
Previous Comments:
[2012-10-26 12:43:29] tony2...@php.net
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=01dee2c4b009d052f0fdfa07f35c181a1ac4aca0
Log: fix bug #63369
[2012-10-26 12:43:08] tony2...@php.net
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f2bffdc2e48174e38a059d425953e8b1c08dd4bf
Log: fix bug #63369
[2012-10-26 12:24:03] tony2...@php.net
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369&patch=the-patch&revision=1351254242
[2012-10-26 12:23:16] tony2...@php.net
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array("test", "1", 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:"stdclass":0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369&edit=1
[PHP-BUG] Bug #63370 [NEW]: ReflectionCLass::getDefaultProperties() return is incorrect for static properti
From: dimzav at gmail dot com
Operating system: Win 7 x64
PHP version: 5.3.18
Package: Reflection related
Bug Type: Bug
Bug description:ReflectionCLass::getDefaultProperties() return is incorrect for
static properti
Description:
ReflectionCLass::getDefaultProperties() returns current value of static
property, not the default one. I can't add comment to
https://bugs.php.net/bug.php?id=51581 but it is evidently a bug and must be
fixed.
Test script:
---
class A
{
public static $a = 1;
}
A::$a = 2;
$reflectionCLass = new ReflectionClass('A');
$defaultProperties = $reflectionCLass->getDefaultProperties();
var_dump($defaultProperties);
Expected result:
Default value of $a static property is 1, it should be returned by
ReflectionCLass::getDefaultProperties() instead of current value.
Actual result:
--
C:\OpenServer\modules\php\PHP-5.3.18\php.exe temp.php
array(1) {
["a"]=>
int(2)
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63370&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63370&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63370&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63370&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63370&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63370&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63370&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63370&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63370&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63370&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63370&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63370&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63370&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63370&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63370&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63370&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63370&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63370&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63370&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63370&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63370&r=mysqlcfg
Req #44033 [Com]: make working abstract methods body in abstract classes
Edit report at https://bugs.php.net/bug.php?id=44033&edit=1
ID: 44033
Comment by: dagguh at gmail dot com
Reported by:giorgio dot liscio at email dot it
Summary:make working abstract methods body in abstract
classes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
You obviously don't know what abstract methods are about.
Learn OOP, please. This is what you want:
customCheck();
}
protected abstract function customCheck();
}
class Real extends Base
{
protected function customCheck()
{
echo("IT IS WORKING!");
}
}
?>
Previous Comments:
[2008-02-03 20:33:53] giorgio dot liscio at email dot it
the requested behavior can works with multiple abstract inheritance
abstract class One
{abstract function m(){echo("one ");}}
abstract class Two extends One
{abstract function m(){parent::m();echo("two ");}}
abstract class Three extends Two
{abstract function m(){parent::m();echo("three ");}}
class RealClass extends Three
{
function m(){parent::m();echo("real implementation");}
}
[2008-02-03 18:57:02] giorgio dot liscio at email dot it
Description:
hello
i think can be useful make working abstract methods body in abstract classes
please read carefully ;) i hope you like it
thank you for your time
Reproduce code:
---
Expected result:
echo("WOW ");
echo("IT IS WORKING!");
Actual result:
--
Fatal error: Abstract function Base::commonCheck() cannot contain body
--
Edit this bug report at https://bugs.php.net/bug.php?id=44033&edit=1
Req #44033 [Com]: make working abstract methods body in abstract classes
Edit report at https://bugs.php.net/bug.php?id=44033&edit=1
ID: 44033
Comment by: dagguh at gmail dot com
Reported by:giorgio dot liscio at email dot it
Summary:make working abstract methods body in abstract
classes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
To promote OOD, this issue should be closed as "won't fix"
Previous Comments:
[2012-10-26 15:59:36] dagguh at gmail dot com
You obviously don't know what abstract methods are about.
Learn OOP, please. This is what you want:
customCheck();
}
protected abstract function customCheck();
}
class Real extends Base
{
protected function customCheck()
{
echo("IT IS WORKING!");
}
}
?>
[2008-02-03 20:33:53] giorgio dot liscio at email dot it
the requested behavior can works with multiple abstract inheritance
abstract class One
{abstract function m(){echo("one ");}}
abstract class Two extends One
{abstract function m(){parent::m();echo("two ");}}
abstract class Three extends Two
{abstract function m(){parent::m();echo("three ");}}
class RealClass extends Three
{
function m(){parent::m();echo("real implementation");}
}
[2008-02-03 18:57:02] giorgio dot liscio at email dot it
Description:
hello
i think can be useful make working abstract methods body in abstract classes
please read carefully ;) i hope you like it
thank you for your time
Reproduce code:
---
Expected result:
echo("WOW ");
echo("IT IS WORKING!");
Actual result:
--
Fatal error: Abstract function Base::commonCheck() cannot contain body
--
Edit this bug report at https://bugs.php.net/bug.php?id=44033&edit=1
Req #62320 [Com]: Abstract static property?
Edit report at https://bugs.php.net/bug.php?id=62320&edit=1
ID: 62320
Comment by: dagguh at gmail dot com
Reported by:techlivezheng at gmail dot com
Summary:Abstract static property?
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
Late Static Binding is a failed concept and should be avoided in all cases.
There is no such thing as static inheritance. Static members of a class belong
to
this class and this class only.
Just use the regular instance methods and regular inheritance.
Your code will be more testable, extensible and modular.
Please close this issue as "won't fix".
Previous Comments:
[2012-06-14 07:04:45] techlivezheng at gmail dot com
Description:
As we have "late static bindings" now, would it be reasonable to have a
"abstract static property"?
See the bellow example.
abstract class A {
//If this could be declared as abstract to make
//the subclass have to redeclare it in order to
//have it own $mTest to use.
//If $mTest is not declared in one subclass, it would
//change the $mTest of A which is shared by many
//subclasses, some unexpected things would happen.
//The design is to make each subclass have its own
//$mTest to use and it has to be existed.
//$mTest in A is just for a skeleton purpose, even should
//not be assigned a value.
static $mTest;
static function setTest($value) {
static::$mTest = $value;
}
static function DumpTest () {
echo 'static:' . static::$mTest . "\n";
echo 'A-self:' . self::$mTest . "\n";
}
}
class B extends A {
static function DumpTest () {
parent::DumpTest();
echo 'B-self:' . self::$mTest . "\n";
echo 'B-parent:' . parent::$mTest . "\n";
}
}
class C extends A {
static $mTest;
static function DumpTest () {
parent::DumpTest();
echo 'C-self:' . self::$mTest . "\n";
echo 'C-parent:' . parent::$mTest . "\n";
}
}
class D extends C {
static $mTest;
static function DumpTest () {
parent::DumpTest();
echo 'D-self:' . self::$mTest . "\n";
echo 'D-parent:' . parent::$mTest . "\n";
}
}
B::setTest('test1');//This will change the $mStorages of class A
B::DumpTest();
//static:test1
//A-self:test1
//B-self:test1
//B-parent:test1
C::setTest('test2');
C::DumpTest();
//static:test2
//A-self:test1
//C-self:test2
//C-parent:test1
D::setTest('test3');
D::DumpTest();
static:test3
//A-self:test1
//C-self:test2
//C-parent:test1
//D-self:test3
//D-parent:test2
--
Edit this bug report at https://bugs.php.net/bug.php?id=62320&edit=1
Req #47971 [Com]: Allow 'static' keyword to be applied to entire classes
Edit report at https://bugs.php.net/bug.php?id=47971&edit=1 ID: 47971 Comment by: dagguh at gmail dot com Reported by:cscott at ggot dot org Summary:Allow 'static' keyword to be applied to entire classes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: What you are referring to is a utility class. It only has static members and a private constructor, which should never be called (even from the class itself). Your suggestion could be useful, because implementing private empty constructors is just boilerplate code. PS. Some people even throw an exception inside the private constructor. Previous Comments: [2009-10-31 00:27:53] cscott at ggot dot org For Relevancy: I do not believe that namespaces solve this problem, as __autoload does not work with namespaces (and, for obvious reasons, shouldn't). [2009-04-14 21:07:14] cscott at ggot dot org Description: Fairly simple: A developer is allowed to define his/her classes as abstract or final, but not as static. For continuity's sake, it would be preferable to be able to declare classes as static as well. This would greatly ease the creation of static function collections/libraries, especially those included with __autoload(). When a class is declared as abstract, it is a statement at the open that this is an incomplete member; you can specify any method inside a class to be abstract and the class is effectively abstract, yet this keyword is allowed in the class declaration. When a class is declared final, it is a statement at the open that all members are to be considered final, and that this class should not be extended any further. By allowing classes to be declared as static, it would follow with allowing "abstract class foo" in the sense that the keyword reflects the contents of the class, and would follow with "final class foo" in that it would define a binding construct for all members of the class. Whether a) In a static class, all methods and members are automatically static -OR- b) In a static class, all methods and members must be declared static Is surely not for me to decide -- either is useful, as it either forces me to ensure all members are static, or it does the legwork for me. As such, I make no suggestion and defer to the wisdom of the developer(s). Thank you for your consideration. -- Edit this bug report at https://bugs.php.net/bug.php?id=47971&edit=1
Req #38569 [Com]: override keyword requested
Edit report at https://bugs.php.net/bug.php?id=38569&edit=1
ID: 38569
Comment by: dagguh at gmail dot com
Reported by:psykora at gmail dot com
Summary:override keyword requested
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Irrelevant
PHP Version:5.1.5
Block user comment: N
Private report: N
New Comment:
This is a valid feature request.
If this change is implemented, the override keyword SHOULD be mandatory for
overridden methods, but this way backwards compatibility would be broken.
Previous Comments:
[2007-12-12 19:52:41] michael at dmgx dot com
Agreed. Currently I use a comment to place the word there just to help myself
out visually. I.E.
public /*override*/ function foo () {}
Override shouldn't be required per se - but if used it should throw an error
when the parent method doesn't exist.
BTW, this has been added to Actionscript 3 which is where I first saw it. Adobe
mentions having the keyword helps out their compiler - so maybe the Zend Engine
could make use of the keyword as well.
[2006-08-23 15:24:19] psykora at gmail dot com
Description:
The override keyword (f.e. like C#.NET has) could be usefull for specifing to
compiler, that current method is overriding parent's class method.
Compiler then should throw Fatal Error when there is no parent's method for
override.
This could resolve common mistakes when developer changes (or removes) abstract
method from parent's class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=38569&edit=1
Bug #53155 [Com]: conditional class creation does not reset static variable in method
Edit report at https://bugs.php.net/bug.php?id=53155&edit=1
ID: 53155
Comment by: dagguh at gmail dot com
Reported by:frederic dot hardy at mageekbox dot net
Summary:conditional class creation does not reset static
variable in method
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: FreeBSD
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Another proof that LSB produces bad code.
Just look at it.
There is no such thing as static inheritance, so maybe you should simply learn
to
code.
Previous Comments:
[2012-05-11 21:05:49] ash at itsash dot co dot uk
I have the same issue on 5.3.6 on Ubuntu.
static::$classVariable with late static binding causes php to override the
parent
static variable.
When using static $methodVariable = 'first_value'; if this is later changed,
by
$methodVariable, when a new instance of that class is initiated, the
$methodVariable SHOULD be 'first_value', however UNEXPECTEDLY it carries over
from any prior instance.
[2010-10-27 02:54:21] fel...@php.net
Probably related to bug #48623
[2010-10-25 21:41:26] frederic dot hardy at mageekbox dot net
Description:
when a class which extends a parent class with a method which define a static
variable is created then a condition is verified, the static variable is not
reset in the chield class.
Test script:
---
0)
{
class b extends a {}
}
var_dump(b::getInstance());
?>
Expected result:
object(a)#1 (0) {
}
object(b)#2 (0) {
}
Actual result:
--
object(a)#1 (0) {
}
object(a)#1 (0) {
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=53155&edit=1
Bug #48623 [Com]: Incorrect scope for static variables in object methods
Edit report at https://bugs.php.net/bug.php?id=48623&edit=1
ID: 48623
Comment by: dagguh at gmail dot com
Reported by:falkon1313 at gmail dot com
Summary:Incorrect scope for static variables in object
methods
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
Why the hell are you using the static keyword?
Use a class field, like normal people do:
stored = $val;
}
return $this->stored;
}
}
$a = new TestClass();
echo $a->test() ."\n";
echo $a->test('alpha') ."\n";
$b = new TestClass();
echo $b->test() ."\n";
echo $b->test('bravo') ."\n";
echo $a->test() ."\n";
TADA! Suddenly you get your expected result
Previous Comments:
[2009-06-21 00:53:14] falkon1313 at gmail dot com
Description:
When a variable is declared static within an object method, it's scope is
spread across all instantiated objects of the class.
This is not a static class variable, nor is it in a static class method, it is
in a method that requires an instantiated object, operates within the context
of that object, and should have the object scope.
Reproduce code:
---
test() ."\n";
echo $a->test('alpha') ."\n";
$b = new TestClass();
echo $b->test() ."\n";
echo $b->test('bravo') ."\n";
echo $a->test() ."\n";
Expected result:
empty
alpha
empty
bravo
alpha
Actual result:
--
empty
alpha
alpha
bravo
bravo
--
Edit this bug report at https://bugs.php.net/bug.php?id=48623&edit=1
Bug #48623 [Com]: Incorrect scope for static variables in object methods
Edit report at https://bugs.php.net/bug.php?id=48623&edit=1
ID: 48623
Comment by: dagguh at gmail dot com
Reported by:falkon1313 at gmail dot com
Summary:Incorrect scope for static variables in object
methods
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
BTW. dont use ifs on non-boolean variables... YUCK!
You should write:
if (isset($val))
Previous Comments:
[2012-10-26 16:21:14] dagguh at gmail dot com
Why the hell are you using the static keyword?
Use a class field, like normal people do:
stored = $val;
}
return $this->stored;
}
}
$a = new TestClass();
echo $a->test() ."\n";
echo $a->test('alpha') ."\n";
$b = new TestClass();
echo $b->test() ."\n";
echo $b->test('bravo') ."\n";
echo $a->test() ."\n";
TADA! Suddenly you get your expected result
[2009-06-21 00:53:14] falkon1313 at gmail dot com
Description:
When a variable is declared static within an object method, it's scope is
spread across all instantiated objects of the class.
This is not a static class variable, nor is it in a static class method, it is
in a method that requires an instantiated object, operates within the context
of that object, and should have the object scope.
Reproduce code:
---
test() ."\n";
echo $a->test('alpha') ."\n";
$b = new TestClass();
echo $b->test() ."\n";
echo $b->test('bravo') ."\n";
echo $a->test() ."\n";
Expected result:
empty
alpha
empty
bravo
alpha
Actual result:
--
empty
alpha
alpha
bravo
bravo
--
Edit this bug report at https://bugs.php.net/bug.php?id=48623&edit=1
Req #54003 [Com]: re-enable abstract static methods
Edit report at https://bugs.php.net/bug.php?id=54003&edit=1
ID: 54003
Comment by: dagguh at gmail dot com
Reported by:giorgio dot liscio at email dot it
Summary:re-enable abstract static methods
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
1. Don't use LSB next time.
2. Use normal inheritance instead.
3. WONTFIX
Previous Comments:
[2012-03-06 04:19:14] cgili at yahoo dot com
Inheritance and method override is something really important on PHP, it's
important to redefine not only the methods but also the parameters they take,
for instance, you have a class Rectangle with a method called Area that
calculates the area in m2 by requiring the height and width, now you want to
create a Cube class extending the Rectangle class, and override the function
Area to calculate the area in cubic meters, the formula is different and the
parameters are 3, height, width and deep. It's the very "BASIC" definition of
Class inheritance and Method Overriding.
[2011-02-13 00:14:32] giorgio dot liscio at email dot it
Description:
hi, please read carefully my request before trash this
since static inheritance is now implemented in php, enabling this again can
provide an awesome natural feature of the language
I talked with some php hackers, and they agree with me, but in past, I did not
have good news about this:
I'm sure my example makes totally sense, and this should stay disabled only if
there are technical limitations that do not matter with the good logic of my
example
in practice, I can understand WONT FIX, but not BOGUS
abstract class AFileSystemItem
{
public static functiongetIfValid ($fullPath)
{
// i use static::isValid to get the method defined in the called class
if(static::isValid($fullPath)) return new static($fullPath);
}
protected function__construct ($fp){}
// i want to force real classes to implement a way to check a path before
instance an object
protected abstract static functionisValid ($fullPath); //
abstract declaration
}
class Dir extends AFileSystemItem
{
protected static function isValid ($fullPath) //
implementation
{
return is_dir($fullPath);
}
}
class File extends AFileSystemItem
{
protected static function isValid ($fullPath) //
implementation
{
return is_file($fullPath);
}
}
class Image extends File
{
protected static function isValid ($fullPath) //
implementation with override
{
if(parent::isValid($fullPath) AND (bool)getimagesize($fullPath))
return true; return false;
}
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=54003&edit=1
Bug #55375 [Com]: Inherited constructor signature: new behavior of PHP5.4 or bug?
Edit report at https://bugs.php.net/bug.php?id=55375&edit=1 ID: 55375 Comment by: dagguh at gmail dot com Reported by:mikaelk...@php.net Summary:Inherited constructor signature: new behavior of PHP5.4 or bug? Status: Open Type: Bug Package:Class/Object related Operating System: Debian Squeeze PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: Abstract constructors? What are you smoking? WONTFIX Previous Comments: [2011-08-06 15:58:36] perraud dot mickael at orange dot fr Perfect, thanks! [2011-08-06 15:52:07] fel...@php.net In fact the behavior has been changed in 5.4, related to bug #51421. I'll add the change to UPGRADING file, thanks. [2011-08-06 15:51:26] paj...@php.net It sounds to me like a bug fix. As the child declaration is more restrictive than the parent declaration, and is against any good design or OO convention. [2011-08-06 11:02:30] mikaelk...@php.net Description: I just experiment this behavior with PHP5.4a3 when running the following code: https://bugs.php.net/bug.php?id=55375&edit=1
Bug #51421 [Com]: Abstract __construct constructor argument list not enforced
Edit report at https://bugs.php.net/bug.php?id=51421&edit=1
ID: 51421
Comment by: dagguh at gmail dot com
Reported by:awood at theiet dot org
Summary:Abstract __construct constructor argument list not
enforced
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Windows XP SP3
PHP Version:5.2SVN-2010-03-29 (snap)
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Abstract constructors again.
Learn some basics of OOP.
Why would you EVER want to enforce argument list of a constructor is beyond me.
I bet you are doing something like:
new $iHaveNoClueAboutProgramming($foo, $bar);
Guess what, this code is bad.
Previous Comments:
[2010-06-28 18:41:25] fel...@php.net
The fix has been reverted for 5.2 and 5.3 branches, due BC issue.
[2010-06-28 18:38:00] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300817
Log: - Reverted fix for bug #51421
[2010-06-27 00:05:15] fel...@php.net
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.
[2010-06-27 00:05:15] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300770
Log: - Fixed bug #51421 (Abstract __construct constructor argument list not
enforced)
[2010-03-29 01:41:53] awood at theiet dot org
Description:
PHP Version = 5.2.6.6
I cannot seem to enforce a class's __construct argument list by defining an
abstract constructor in the base class. This can, however, be achieved as
expected by using an object interface.
This was mistakenly reported as not working for interfaces either in bug #43557
(closed).
Test script:
---
class Type1 {} //for demo purposes
class Type2 {} //for demo purposes
abstract class BaseClass {
abstract public function __construct(Type1 $foo, Type2 $bar);
}
class ExtendedClass extends BaseClass {
public function __construct() {
//expected - fatal error as argument list doesn't match
//actually happens - nothing, script continues as normal
}
}
interface SomeInterface {
public function __construct(Type1 $foo, Type2 $bar);
}
class InterfacedClass implements SomeInterface {
public function __construct() {
//generates fatal error as expected
}
}
Expected result:
Fatal error when declaring ExtendedClass and InterfacedClass as abstract and
concrete method signatures are different.
Actual result:
--
Only a fatal error when declaring InterfacedClass, no error when declaring
ExtendedClass.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51421&edit=1
Bug #63180 [Asn->Csd]: Corruption of hash tables (bugfix attached)
Edit report at https://bugs.php.net/bug.php?id=63180&edit=1
ID: 63180
Updated by: dmi...@php.net
Reported by:vesselin dot atanasov at gmail dot com
Summary:Corruption of hash tables (bugfix attached)
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4Git-2012-09-28 (Git)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of dmi...@zend.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=68b229ea73b5e975951b5ad02ffb315ec60fca1e
Log: Fixed bug #63180 (Corruption of hash tables)
Previous Comments:
[2012-10-01 12:23:06] vesselin dot atanasov at gmail dot com
One option would be to store interned pointers without copying when one of the
two is true:
1. Either the hash table is non-persistent.
2. Or when the hash table is persistent and (the interned string is below the
interned snapshot top or there is no snapshot top defined at all).
What do you think of this approach?
[2012-10-01 11:49:34] dmi...@php.net
These tables store internal entities, that are never changed from request to
request, and also entities created during compilation and execution, that are
destroyed at end of request.
[2012-10-01 11:39:38] vesselin dot atanasov at gmail dot com
I took a look at the EG(function_table), EG(class_table), EG(zend_constants)
and indeed they are persistent.
What were the reasons for making these tables persistent? Was it just for
performance reasons?
[2012-10-01 07:08:11] dmi...@php.net
In general, this is the right observation and the right fix.
However, this fix won't allow interned strings usage in EG(function_table),
EG(class_table) and EG(zend_constants). This is going to lead to larger memory
consumption and slower execution.
I think, that might be better to workaround the problem in PCRE extension
itself. I know, it's not "sexy" and some other places might need to be fixed as
well. :( May be you can think about better solution?
[2012-09-28 16:18:49] vesselin dot atanasov at gmail dot com
Description:
PHP 5.4 has a bug in the handling if interned (literal) strings.
Each time an HTTP request terminates, the interned strings are restored to the
snapshot that was taken at the end of the startup sequence, which
effectively removes any interned strings that have been added after the
snapshot has been made.
Usually when a hash item is added, the code in zend_hash.c allocates extra
space after the end of the Bucket structure, copies the key there and then
points Bucket::arKey to the key copy. However when dealing with interned hash
keys the code tries to optimize the algorithm by not allocating extra
space after the end of the Bucket structure, but just pointing Bucket::arKey to
the passed arKey parameter.
if (IS_INTERNED(arKey)) {
p = (Bucket *) pemalloc(sizeof(Bucket), ht->persistent);
if (!p) {
return FAILURE;
}
p->arKey = arKey;
} else {
p = (Bucket *) pemalloc(sizeof(Bucket) + nKeyLength,
ht->persistent);
if (!p) {
return FAILURE;
}
p->arKey = (const char*)(p + 1);
memcpy((char*)p->arKey, arKey, nKeyLength);
}
The problem happens when a persistent hash table gets an interned key as a
parameter. What happens is that the table and its bucket are persistent, i.e.
they remain even after the current HTTP request has been terminated, but the
bucket key is removed from the interned keys table and its memory will be
reused by other interned keys upon the next request. This leads to corruption
of the array keys in the persistent hash table.
One such case is with the PCRE cache. It is initialized in:
php_pcre.c:PHP_GINIT_FUNCTION(pcre)
by the following code:
zend_hash_init(&pcre_globals->pcre_cache, 0, NULL, php_free_pcre_cache, 1);
The last parameter (1) means that it is a persistent hash table. However the
code in
php_pcre.c:pcre_get_compiled_regex_cache(char *regex, int regex_len TSRMLS_DC)
just passes the regex parameter to zend_hash_update:
zend_hash_update(&PCRE_G(pcre_cache), regex, regex_len+1, (void *)&new_entry,
sizeof(pcre_cache_entry), (void**)&pce);
Given that in most cases the regex parameter is created from string literals in
the compiled code, this means that in most cases we end up with
in
Bug #63180 [Csd->Asn]: Corruption of hash tables (bugfix attached)
Edit report at https://bugs.php.net/bug.php?id=63180&edit=1 ID: 63180 Updated by: dmi...@php.net Reported by:vesselin dot atanasov at gmail dot com Summary:Corruption of hash tables (bugfix attached) -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Any PHP Version:5.4Git-2012-09-28 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: Your proposal will work, but it will slowdown every HashTable update operation. However these checks are really necessary only for very few cases. I prefer to fix the problem with a hack. I've just committed the fix. Previous Comments: [2012-10-26 16:49:51] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=68b229ea73b5e975951b5ad02ffb315ec60fca1e Log: Fixed bug #63180 (Corruption of hash tables) [2012-10-01 12:23:06] vesselin dot atanasov at gmail dot com One option would be to store interned pointers without copying when one of the two is true: 1. Either the hash table is non-persistent. 2. Or when the hash table is persistent and (the interned string is below the interned snapshot top or there is no snapshot top defined at all). What do you think of this approach? [2012-10-01 11:49:34] dmi...@php.net These tables store internal entities, that are never changed from request to request, and also entities created during compilation and execution, that are destroyed at end of request. [2012-10-01 11:39:38] vesselin dot atanasov at gmail dot com I took a look at the EG(function_table), EG(class_table), EG(zend_constants) and indeed they are persistent. What were the reasons for making these tables persistent? Was it just for performance reasons? [2012-10-01 07:08:11] dmi...@php.net In general, this is the right observation and the right fix. However, this fix won't allow interned strings usage in EG(function_table), EG(class_table) and EG(zend_constants). This is going to lead to larger memory consumption and slower execution. I think, that might be better to workaround the problem in PCRE extension itself. I know, it's not "sexy" and some other places might need to be fixed as well. :( May be you can think about better solution? 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=63180 -- Edit this bug report at https://bugs.php.net/bug.php?id=63180&edit=1
Bug #63180 [Asn->Csd]: Corruption of hash tables (bugfix attached)
Edit report at https://bugs.php.net/bug.php?id=63180&edit=1 ID: 63180 Updated by: dmi...@php.net Reported by:vesselin dot atanasov at gmail dot com Summary:Corruption of hash tables (bugfix attached) -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Any PHP Version:5.4Git-2012-09-28 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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: [2012-10-26 16:54:01] dmi...@php.net Your proposal will work, but it will slowdown every HashTable update operation. However these checks are really necessary only for very few cases. I prefer to fix the problem with a hack. I've just committed the fix. [2012-10-26 16:49:51] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=68b229ea73b5e975951b5ad02ffb315ec60fca1e Log: Fixed bug #63180 (Corruption of hash tables) [2012-10-01 12:23:06] vesselin dot atanasov at gmail dot com One option would be to store interned pointers without copying when one of the two is true: 1. Either the hash table is non-persistent. 2. Or when the hash table is persistent and (the interned string is below the interned snapshot top or there is no snapshot top defined at all). What do you think of this approach? [2012-10-01 11:49:34] dmi...@php.net These tables store internal entities, that are never changed from request to request, and also entities created during compilation and execution, that are destroyed at end of request. [2012-10-01 11:39:38] vesselin dot atanasov at gmail dot com I took a look at the EG(function_table), EG(class_table), EG(zend_constants) and indeed they are persistent. What were the reasons for making these tables persistent? Was it just for performance reasons? 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=63180 -- Edit this bug report at https://bugs.php.net/bug.php?id=63180&edit=1
Req #50815 [Com]: Implement 323 short password hash fallback in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=50815&edit=1 ID: 50815 Comment by: toddr at cpanel dot net Reported by:jd at cpanel dot net Summary:Implement 323 short password hash fallback in mysqlnd Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.3.1 Assigned To:mysql Block user comment: N Private report: N New Comment: If all MySQL 5 versions support this hashing scheme, Aren't you kinda overriding a user decision to enable short passwords on their MySQL server? It's also not clear when the failure happens what the problem is. Previous Comments: [2010-08-27 06:00:08] ahar...@php.net Fix up the package to make this easier to search for. [2010-08-26 13:31:35] u...@php.net We mysql guys have no plans adding old insecure password stuff to mysqlnd. As it is assigned to us/me, I'm changing status to what shall be status from our/my perspective: won't fix. [2010-03-03 16:57:40] chris at geartech dot org I am running into this issue with mysqlnd as well; at my work we must keep old passwords on a few daemons to ensure backwards compatibility with proprietary software. MySQL's website (checking the 5.1 & 5.5 documentation) doesn't have the old password format deprecated in the newer versions, it's merely discouraged. While I agree that it is an insecure format and deprecating/removing support of it would be ideal, but it seems like support for this password scheme will exist in (major) future versions. [2010-01-21 19:17:49] jd at cpanel dot net I'd agree with you there. They should be using the long hashes. The problem is when you have a system that's been in place for a very long time and the passwords haven't ever changed. The short hashes are still in the user table and the existing libmysqlclient happily connects with them. For some users this makes switching to mysqlnd a very difficult process. You need to force all of these old account to reenter their passwords so they can be rehashed. The main point is that if it's insecure to the point where it's worth breaking backward compatability, why do the latest versions of libmysqlclient continue to provide this functionality? The short hashes in the user table are the security problem, not the ability to send them from the client side, right? [2010-01-21 19:07:00] johan...@php.net The old hashing algorithm was insecure, which means passwords could be guessed with little effort. Additionally the last MySQL Server version which depended on this format is 4.0, which is out-of-support by MySQL (see http://www.mysql.com/about/legal/lifecycle/ ) since 2006 (extended support for customers ended 2008-09). Why do you need an insecure auth mechanism? 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=50815 -- Edit this bug report at https://bugs.php.net/bug.php?id=50815&edit=1
[PHP-BUG] Req #63371 [NEW]: Overriding method with an abstract method
From: dagguh at gmail dot com
Operating system: Irrelevant
PHP version: 5.3.18
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Overriding method with an abstract method
Description:
In Java you can override a method with an abstract one, but in PHP it
results in:
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
Test script:
---
class HttpNotFoundException extends RestResponseException {
public function getHttpStatusCode() {
// ...
}
}
abstract class RestResponseException extends IdentifiableException {
public abstract function getHttpStatusCode();
}
class IdentifiableException extends Exception {
// ...
}
// --- and here come the tests:
class HttpNotFoundExceptionTests extends RestResponseExceptionTests {
protected function getSystemUnderTest() {
return new HttpNotFoundException();
}
// ... tests logic specific to HttpNotFoundException
}
class RestResponseExceptionTests extends IdentifiableExceptionTests {
/**
* @return RestResponseException
*/
protected abstract function getSystemUnderTest();
// ... tests specific for RestResponseException, even though it is an
abstract class, it has some logic implemented and tests for that portion of
logic are specified here. It is important to note that while
getSystemUnderTest() method in IdentifiableExceptionTests expects
IdentifiableException, in RestResponseExceptionTests it expects
RestResponseException, which is a proper subclass of IdentifiableException
}
class IdentifiableExceptionTests extends PHPUnit_Framework_TestCase {
/**
* @return IdentifiableException
*/
protected function getSystemUnderTest() {
return new IdentifiableException();
}
//... tests IdentifiableException logic
}
Expected result:
I expect this code to work.
It works in Java, so why cannot it work in PHP?
Actual result:
--
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
--
Edit bug report at https://bugs.php.net/bug.php?id=63371&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63371&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63371&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63371&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63371&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63371&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63371&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63371&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63371&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63371&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63371&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63371&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63371&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63371&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63371&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63371&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63371&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63371&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63371&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63371&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63371&r=mysqlcfg
Req #50815 [Com]: Implement 323 short password hash fallback in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=50815&edit=1 ID: 50815 Comment by: toddr at cpanel dot net Reported by:jd at cpanel dot net Summary:Implement 323 short password hash fallback in mysqlnd Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.3.1 Assigned To:mysql Block user comment: N Private report: N New Comment: If you want to discourage use of the short password method, couldn't you just add a configure option to enable this and disable it by default? Previous Comments: [2012-10-26 17:11:47] toddr at cpanel dot net If all MySQL 5 versions support this hashing scheme, Aren't you kinda overriding a user decision to enable short passwords on their MySQL server? It's also not clear when the failure happens what the problem is. [2010-08-27 06:00:08] ahar...@php.net Fix up the package to make this easier to search for. [2010-08-26 13:31:35] u...@php.net We mysql guys have no plans adding old insecure password stuff to mysqlnd. As it is assigned to us/me, I'm changing status to what shall be status from our/my perspective: won't fix. [2010-03-03 16:57:40] chris at geartech dot org I am running into this issue with mysqlnd as well; at my work we must keep old passwords on a few daemons to ensure backwards compatibility with proprietary software. MySQL's website (checking the 5.1 & 5.5 documentation) doesn't have the old password format deprecated in the newer versions, it's merely discouraged. While I agree that it is an insecure format and deprecating/removing support of it would be ideal, but it seems like support for this password scheme will exist in (major) future versions. [2010-01-21 19:17:49] jd at cpanel dot net I'd agree with you there. They should be using the long hashes. The problem is when you have a system that's been in place for a very long time and the passwords haven't ever changed. The short hashes are still in the user table and the existing libmysqlclient happily connects with them. For some users this makes switching to mysqlnd a very difficult process. You need to force all of these old account to reenter their passwords so they can be rehashed. The main point is that if it's insecure to the point where it's worth breaking backward compatability, why do the latest versions of libmysqlclient continue to provide this functionality? The short hashes in the user table are the security problem, not the ability to send them from the client side, right? 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=50815 -- Edit this bug report at https://bugs.php.net/bug.php?id=50815&edit=1
Req #63371 [Com]: Overriding method with an abstract method
Edit report at https://bugs.php.net/bug.php?id=63371&edit=1
ID: 63371
Comment by: hanskrentel at yahoo dot de
Reported by:dagguh at gmail dot com
Summary:Overriding method with an abstract method
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Irrelevant
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
> It works in Java, so why cannot it work in PHP?
Because PHP is PHP and Java is Java. So where to file the bug-report? Shouldn't
it
be reported as a bug at Java, because Java doesn't do it like PHP?
Previous Comments:
[2012-10-26 17:16:30] dagguh at gmail dot com
Description:
In Java you can override a method with an abstract one, but in PHP it results
in:
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
Test script:
---
class HttpNotFoundException extends RestResponseException {
public function getHttpStatusCode() {
// ...
}
}
abstract class RestResponseException extends IdentifiableException {
public abstract function getHttpStatusCode();
}
class IdentifiableException extends Exception {
// ...
}
// --- and here come the tests:
class HttpNotFoundExceptionTests extends RestResponseExceptionTests {
protected function getSystemUnderTest() {
return new HttpNotFoundException();
}
// ... tests logic specific to HttpNotFoundException
}
class RestResponseExceptionTests extends IdentifiableExceptionTests {
/**
* @return RestResponseException
*/
protected abstract function getSystemUnderTest();
// ... tests specific for RestResponseException, even though it is an
abstract class, it has some logic implemented and tests for that portion of
logic are specified here. It is important to note that while
getSystemUnderTest() method in IdentifiableExceptionTests expects
IdentifiableException, in RestResponseExceptionTests it expects
RestResponseException, which is a proper subclass of IdentifiableException
}
class IdentifiableExceptionTests extends PHPUnit_Framework_TestCase {
/**
* @return IdentifiableException
*/
protected function getSystemUnderTest() {
return new IdentifiableException();
}
//... tests IdentifiableException logic
}
Expected result:
I expect this code to work.
It works in Java, so why cannot it work in PHP?
Actual result:
--
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
--
Edit this bug report at https://bugs.php.net/bug.php?id=63371&edit=1
Bug #63370 [Com]: ReflectionCLass::getDefaultProperties() return is incorrect for static properti
Edit report at https://bugs.php.net/bug.php?id=63370&edit=1
ID: 63370
Comment by: hanskrentel at yahoo dot de
Reported by:dimzav at gmail dot com
Summary:ReflectionCLass::getDefaultProperties() return is
incorrect for static properti
Status: Open
Type: Bug
Package:Reflection related
Operating System: Win 7 x64
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
Please do not create a duplicate of the existing issue #51581. There was a
decision to not fix it for some reasons.
Also IMHO default values for global static class variables are as useful as
getting default values for other global variables.
You might have more luck in requesting a general reflection features for
variables - global ones, local ones, static ones and class static ones.
Previous Comments:
[2012-10-26 14:01:45] dimzav at gmail dot com
Description:
ReflectionCLass::getDefaultProperties() returns current value of static
property, not the default one. I can't add comment to
https://bugs.php.net/bug.php?id=51581 but it is evidently a bug and must be
fixed.
Test script:
---
class A
{
public static $a = 1;
}
A::$a = 2;
$reflectionCLass = new ReflectionClass('A');
$defaultProperties = $reflectionCLass->getDefaultProperties();
var_dump($defaultProperties);
Expected result:
Default value of $a static property is 1, it should be returned by
ReflectionCLass::getDefaultProperties() instead of current value.
Actual result:
--
C:\OpenServer\modules\php\PHP-5.3.18\php.exe temp.php
array(1) {
["a"]=>
int(2)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63370&edit=1
Bug #63368 [Com]: Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone
Edit report at https://bugs.php.net/bug.php?id=63368&edit=1 ID: 63368 Comment by: hanskrentel at yahoo dot de Reported by:mega dot venik at gmail dot com Summary:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone Status: Open Type: Bug Package:PHP options/info functions Operating System: Centos 6.3 PHP Version:5.3.18 Block user comment: N Private report: N New Comment: > Why PHP doesn't read the timezone value from the global config file? Actually it does. Please double check the setting in the global php.ini configuration file. The FCGI PHP binary on your system might be configured to fetch a different global php.ini than the one you named: /etc/php.ini The error is likely on your end and configuration. Please double-check which php.ini is used with your fcgi configuration. Previous Comments: [2012-10-26 11:36:29] mega dot venik at gmail dot com correction [2012-10-26 11:35:05] mega dot venik at gmail dot com Description: There's a Centos6.3 system. Apache 2.2.15 + mod_fcgid + PHP 5.3.3 There's a problem with date.timezone value. It's mentioned in the global /etc/php.ini like this: date.timezone = "Europe/Moscow" And doesn't mentioned in user's local php.ini. As a result, I'm getting lot's of warnings like: Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead in ... Including the date.timezone parameter into the user's php.ini solves the problem, but I don't think, that it's the best solution. Why PHP doesn't read the timezone value from the global config file? Thanks! -- Edit this bug report at https://bugs.php.net/bug.php?id=63368&edit=1
Bug #63370 [Opn]: ReflectionCLass::getDefaultProperties() return is incorrect for static properti
Edit report at https://bugs.php.net/bug.php?id=63370&edit=1
ID: 63370
User updated by:dimzav at gmail dot com
Reported by:dimzav at gmail dot com
Summary:ReflectionCLass::getDefaultProperties() return is
incorrect for static properti
Status: Open
Type: Bug
Package:Reflection related
Operating System: Win 7 x64
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
Reasons given are:
Of course it might be used in ext/Reflection but it would require
less-efficient and more-memory-consumption implementation which would affect
any php script which use classes with static properties.
I don't understand why performance issue should be excuse for bug. And I can't
add comments to that bug, so what else can I do? Only create new ticket for bug
which is evident and can't be excused by any performance reasons.
Previous Comments:
[2012-10-26 17:32:49] hanskrentel at yahoo dot de
Please do not create a duplicate of the existing issue #51581. There was a
decision to not fix it for some reasons.
Also IMHO default values for global static class variables are as useful as
getting default values for other global variables.
You might have more luck in requesting a general reflection features for
variables - global ones, local ones, static ones and class static ones.
[2012-10-26 14:01:45] dimzav at gmail dot com
Description:
ReflectionCLass::getDefaultProperties() returns current value of static
property, not the default one. I can't add comment to
https://bugs.php.net/bug.php?id=51581 but it is evidently a bug and must be
fixed.
Test script:
---
class A
{
public static $a = 1;
}
A::$a = 2;
$reflectionCLass = new ReflectionClass('A');
$defaultProperties = $reflectionCLass->getDefaultProperties();
var_dump($defaultProperties);
Expected result:
Default value of $a static property is 1, it should be returned by
ReflectionCLass::getDefaultProperties() instead of current value.
Actual result:
--
C:\OpenServer\modules\php\PHP-5.3.18\php.exe temp.php
array(1) {
["a"]=>
int(2)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63370&edit=1
Bug #63368 [Opn]: Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone
Edit report at https://bugs.php.net/bug.php?id=63368&edit=1 ID: 63368 User updated by:mega dot venik at gmail dot com Reported by:mega dot venik at gmail dot com Summary:Apache 2.2.15 + mod_fcgid + PHP 5.3.3 ignores global timezone Status: Open Type: Bug Package:PHP options/info functions Operating System: Centos 6.3 PHP Version:5.3.18 Block user comment: N Private report: N New Comment: > Actually it does. Please double check the setting in the global php.ini configuration file. The FCGI PHP binary on your system might be configured to fetch a different global php.ini than the one you named: /etc/php.ini Nope. Everything's fine, as I can see here: Configure Command './configure' '--build=x86_64-unknown-linux-gnu' '--host=x86_64-unknown-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--without-sqlite' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/lib64/mysql/mysql_config' '--enable-dom=shared' '--with-pgsql=shared' '--enable-wddx=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,/usr/lib64/mysql/mysql_config' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--with-sqlite3=shared,/usr' '--enable-json=shared' '--enable-zip=shared' '--without-readline' '--with-libedit' '--with-pspell=shared' '--enable-phar=shared' '--with-tidy=shared,/usr' '--enable-sysvmsg=shared' '--enable-sysvshm=shared' '--enable-sysvsem=shared' '--enable-posix=shared' '--with-unixODBC=shared,/usr' '--enable-fileinfo=shared' '--enable-intl=shared' '--with-icu-dir=/usr' '--with-enchant=shared,/usr' '--with-recode=shared,/usr' Server API CGI/FastCGI Virtual Directory Support disabled Configuration File (php.ini) Path /etc Loaded Configuration File /var/www/php-bin/adminhost-dns/php.ini Scan this dir for additional .ini files /etc/php.d Previous Comments: [2012-10-26 17:38:19] hanskrentel at yahoo dot de > Why PHP doesn't read the timezone value from the global config file? Actually it does. Please double check the setting in the global php.ini configuration file. The FCGI PHP binary on your system might be configured to fetch a different global php.ini than the one you named: /etc/php.ini The error is likely on your end and configuration. Please double-check which php.ini is used with your fcgi configuration. [2012-10-26 11:36:29] mega dot venik at gmail dot com correction [2012-10-26 11:35:05] mega dot venik at gmail dot com Description: There's a Centos6.3 system. Apache 2.2.15 + mod_fcgid + PHP 5.3.3 There's a problem with date.timezone value. It's mentioned in the global /etc/php.ini like this: date.timezone = "Europe/Moscow" And doesn't mentioned in user's local php.ini. As a result, I'm getting lot's of warnings like: Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the
Req #63371 [Com]: Overriding method with an abstract method
Edit report at https://bugs.php.net/bug.php?id=63371&edit=1
ID: 63371
Comment by: dagguh at gmail dot com
Reported by:dagguh at gmail dot com
Summary:Overriding method with an abstract method
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Irrelevant
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
@hanskrentel:
I made the comparison, because Java is generally more restrictive than PHP.
This time, it is PHP which imposes a restriction, which is not present in Java.
Furthermore, this restriction is aribtrary and completely unnecessary.
Moreover, PHP is strongly influenced from Java since PHP5.
Previous Comments:
[2012-10-26 17:23:52] hanskrentel at yahoo dot de
> It works in Java, so why cannot it work in PHP?
Because PHP is PHP and Java is Java. So where to file the bug-report? Shouldn't
it
be reported as a bug at Java, because Java doesn't do it like PHP?
[2012-10-26 17:16:30] dagguh at gmail dot com
Description:
In Java you can override a method with an abstract one, but in PHP it results
in:
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
Test script:
---
class HttpNotFoundException extends RestResponseException {
public function getHttpStatusCode() {
// ...
}
}
abstract class RestResponseException extends IdentifiableException {
public abstract function getHttpStatusCode();
}
class IdentifiableException extends Exception {
// ...
}
// --- and here come the tests:
class HttpNotFoundExceptionTests extends RestResponseExceptionTests {
protected function getSystemUnderTest() {
return new HttpNotFoundException();
}
// ... tests logic specific to HttpNotFoundException
}
class RestResponseExceptionTests extends IdentifiableExceptionTests {
/**
* @return RestResponseException
*/
protected abstract function getSystemUnderTest();
// ... tests specific for RestResponseException, even though it is an
abstract class, it has some logic implemented and tests for that portion of
logic are specified here. It is important to note that while
getSystemUnderTest() method in IdentifiableExceptionTests expects
IdentifiableException, in RestResponseExceptionTests it expects
RestResponseException, which is a proper subclass of IdentifiableException
}
class IdentifiableExceptionTests extends PHPUnit_Framework_TestCase {
/**
* @return IdentifiableException
*/
protected function getSystemUnderTest() {
return new IdentifiableException();
}
//... tests IdentifiableException logic
}
Expected result:
I expect this code to work.
It works in Java, so why cannot it work in PHP?
Actual result:
--
Fatal error: Cannot make non abstract method
IdentifiableExceptionTests::getSystemUnderTest() abstract in class
RestResponseExceptionTests in xxx on line yyy
--
Edit this bug report at https://bugs.php.net/bug.php?id=63371&edit=1
Req #63298 [Com]: Nothing resolves upwards in PHP
Edit report at https://bugs.php.net/bug.php?id=63298&edit=1 ID: 63298 Comment by: dagguh at gmail dot com Reported by:nat at nath dot is Summary:Nothing resolves upwards in PHP Status: Open Type: Feature/Change Request Package:*General Issues Operating System: Unix PHP Version:5.4.7 Block user comment: N Private report: N New Comment: your Animal class is not in global namespace, but in MyProject. You gotta import it via: use MyProject\Animal; This request is invalid BTW. Namespaces should be all in lowercase. Previous Comments: [2012-10-17 22:25:08] nat at nath dot is Description: --- >From manual page: http://www.php.net/language.namespaces.global --- I would love to use namespaces, but it seems kind of silly that nothing in PHP resolves upwards (be that variables, classes, constants or functions). Test script: --- https://gist.github.com/3908714/c7639b02a8a4fc2c13ebfbcb35e41d17ab1b8d44 Expected result: whoof Actual result: -- Fatal error: Class 'MyProject\Animal\Animal' not found in /Users/Nathaniel/Projects/test/animal/dog.php on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=63298&edit=1
Req #62574 [Com]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 Comment by: dagguh at gmail dot com Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This is valid. @ajf: You should never dop anything "ahead-of-time" in programming. You shoudl escape a variable right before passing it to en environment, that requires this form of escaping Previous Comments: [2012-09-04 18:15:37] ajf at ajf dot me (I'm all for this though, I'm just pointing out other options) [2012-09-04 18:06:32] ajf at ajf dot me You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) [2012-07-16 04:07:43] thbley at gmail dot com Description: old: new: echo <$str>; ?> or: -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Bug #62537 [Com]: Composed class has fatal error with duplicate, equal array properties
Edit report at https://bugs.php.net/bug.php?id=62537&edit=1
ID: 62537
Comment by: dagguh at gmail dot com
Reported by:jeremeamia at gmail dot com
Summary:Composed class has fatal error with duplicate, equal
array properties
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Ubuntu
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
If it is logically the same thing, it should be only in one of these traits,
don't
you think?
SRP and DRY, fellas
Previous Comments:
[2012-07-20 09:07:13] ahar...@php.net
I'd call this a bug, rather than a documentation issue; if Foo::$var ===
Bar::$var, I can't really see why it should fatal.
Reclassifying, and we'll see what the engine folk think.
[2012-07-12 01:36:55] jeremeamia at gmail dot com
Another test script, which might be even more relevant:
trait Foo {public $var = [];}
class Bar {use Foo; public $var = [];}
This also causes a fatal error for me, which should only be a strict error
based
on the documentation.
[2012-07-11 19:45:00] jeremeamia at gmail dot com
Description:
---
>From manual page: http://www.php.net/language.oop5.traits
---
The manual says, "If a trait defines a property then a class can not define a
property with the same name, otherwise an error is issued. It is an E_STRICT if
the class definition is compatible (same visibility and initial value) or fatal
error otherwise."
This does not appear to be true when the same-named properties have array
values.
See the test script for a quick example. It seems that it behaves as the
documentation describes only with scalar values.
This is either missing/erroneous documentation (i.e. the behavior is intended),
or
it is a bug (i.e. equal array values should not cause a fatal error).
Test script:
---
trait Foo {public $var = [];}
trait Bar {public $var = [];}
class Baz {use Foo, Bar;}
Expected result:
To behave as the documentation describes, i.e. no fatal errors occuring.
Actual result:
--
PHP Fatal error: Foo and Bar define the same property ($var) in the
composition
of Baz. However, the definition differs and is considered incompatible.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62537&edit=1
Req #62519 [Com]: Find out about a function's call context
Edit report at https://bugs.php.net/bug.php?id=62519&edit=1
ID: 62519
Comment by: j_holland at hotmail dot com
Reported by:awilliams at linkme dot com dot au
Summary:Find out about a function's call context
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The reason to expose the calling context is so that the function can confirm
it's correct:
function calculate_something($args){
if (get_calling_context() == "VOID") {
print "ERROR: must be called in non-void context!";
exit;
}
return do_expensive_calculation($args);
}
This might be unnecessary in your own code but it's VERY useful when writing
libraries. Perl has this function (wantarray) and I use it whenever I write
libraries.
Yes, this function can be misused, but so can most functions.
Overloading the return keyword is a terrible way to implement this. Make it a
clearly named function, like get_calling_context.
Finally, it would probably be sufficient to simply return void/non-void
context, but more specific context is known:
print function();// the RV will be evaluated as a string
$a = 3 + function(); // the RV will be treated as a number
if (function()));// the RV will be treated as a Boolean
etc.
Previous Comments:
[2012-07-12 01:51:00] johan...@php.net
You could pass an additional parameter to the function
function ($foo, $return) {
if ($return) {
return $foo;
} else {
echo $foo;
}
}
Many people would say that changing the behavior of a function from it's use
case is bad.
I'm also not sure we can implement this without adding overhead to *all*
function calls, which we won't like to do.
[2012-07-11 11:31:07] awilliams at linkme dot com dot au
I would like to present a more concrete example of why I think this would be an
elegant solution to a coding dilemma I have.
I wrote a couple of functions to generate html for mark-up from mySql
tables and php arrays.
Some times I want to call them directly and I want then to output the html,
other times I want to use them in string expressions, in which case I want them
to return the html.
As it stands I would have to do this using different function names, which
looks messy.
To implement this I have two choices, maintain two separate functions doing
almost the same thing. That is never best practice. Sooner or later you
forget to do a change to both of them.
Declare the string returning function and call it from the string printing
version. This is wasteful of stack and call time resources, I try not to code
like that.
I am left looking at this thinking it would be a really elegant solution if the
function its self could tell what context it was called in and either echo or
return the output as required.
I agree that itâs a somewhat unconventional suggestion. I wouldn't expect it
of 'C'. I write in PHP because many things are simpler an more flexible here,
and this would definitely add a new form of flexibility that I have a use for.
Thank you and that's my last word on it.
Alan
[2012-07-10 14:01:11] ni...@php.net
PHP is a dynamically typed language. It can't in the general case know what
type is expected. Simple example if f1() + f2(). Here int, float and array
would be viable return types.
Whether the return value is used or not is known to the engine and also exposed
to internal functions.
But I don't think that it makes sense to expose it to userland functions.
Functions shouldn't behave different based on whether the return value is used
or not.
[2012-07-10 04:10:55] awilliams at linkme dot com dot au
Description:
I would like to be able to tell if a function was called from a context that is
expecting a return value or not. Additionally what type is expected.
eg('hello');// called not expecting a return value
echo eg('hello').' world'; // called expecting a string
function eg($s)
{
if(return){ // suggested overloading of the return keyword to report the
function context.
return ($s);
}
else{
echo $s;
}
}
Additionally
gettype(return);
and
is_string(return);
is_array(return);
etc
--
Edit this bug report at https://bugs.php.net/bug.php?id=62519&edit=1
Req #62435 [Com]: Shorted if and references handling
Edit report at https://bugs.php.net/bug.php?id=62435&edit=1 ID: 62435 Comment by: dagguh at gmail dot com Reported by:grzegorz129 at gmail dot com Summary:Shorted if and references handling Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: N/A PHP Version:5.4.4 Block user comment: N Private report: N New Comment: "Short if" is known as ternary operator. What you want to write is: $this->_currentExceptionInfo =& ((isset($this->_exceptionsMap[$code])) ? $this- >_exceptionsMap[$code] : $this->_exceptionsMap[self::X_INTERNAL]); BTW. Using references is a bad idea. This request is invalid. Previous Comments: [2012-06-28 09:41:09] grzegorz129 at gmail dot com Description: PHP doesn't allow to use references in short if construction - I don't have idea why it's limited. I think it should be improved in future releases. Test script: --- $this->_currentExceptionInfo = ((isset($this->_exceptionsMap[$code])) ? &$this->_exceptionsMap[$code] : &$this->_exceptionsMap[self::X_INTERNAL]); //Error //The same function but it works as expected if(isset($this->_exceptionsMap[$code])) $this->_currentExceptionInfo = &$this->_exceptionsMap[$code]; else $this->_currentExceptionInfo = &$this->_exceptionsMap[self::X_INTERNAL]; -- Edit this bug report at https://bugs.php.net/bug.php?id=62435&edit=1
[PHP-BUG] Bug #63372 [NEW]: Namespace Declaration Missing Parse Error
From: hanskrentel at yahoo dot de
Operating system:
PHP version: 5.4.8
Package: Class/Object related
Bug Type: Bug
Bug description:Namespace Declaration Missing Parse Error
Description:
The following file namespace declaration:
namespace \Name;
Does not give a Parse Error. It's sister declaration:
namespace \Name {}
does.
Test script:
---
https://bugs.php.net/bug.php?id=63372&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63372&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63372&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63372&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63372&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63372&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63372&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63372&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63372&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63372&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63372&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63372&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63372&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63372&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63372&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63372&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63372&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63372&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63372&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63372&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63372&r=mysqlcfg
Req #62574 [Com]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 Comment by: ajf at ajf dot me Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: @dagguh: What? I'm just suggesting exporting variables into the global namespace, and escaping them in the process, for templating purposes. Previous Comments: [2012-10-26 19:07:08] dagguh at gmail dot com This is valid. @ajf: You should never dop anything "ahead-of-time" in programming. You shoudl escape a variable right before passing it to en environment, that requires this form of escaping [2012-09-04 18:15:37] ajf at ajf dot me (I'm all for this though, I'm just pointing out other options) [2012-09-04 18:06:32] ajf at ajf dot me You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) [2012-07-16 04:07:43] thbley at gmail dot com Description: old: new: echo <$str>; ?> or: -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Bug #54256 [Com]: DirectoryIterator isn't iterable with a foreach
Edit report at https://bugs.php.net/bug.php?id=54256&edit=1
ID: 54256
Comment by: maurice dot k at zend dot com
Reported by:gege2061 at homecomputing dot fr
Summary:DirectoryIterator isn't iterable with a foreach
Status: Feedback
Type: Bug
Package:SPL related
Operating System: Debian unstable
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The same problem occurs with Parallels Workstation under Windows 7, when using
shared folders. DirectoryIterator is not iteratable using foreach.
Windows 7
Parallels Workstation v6
Linux Ubuntu 12.04.1-LTS
Any suggested workaround?
Previous Comments:
[2011-09-23 07:01:25] sniper dot unreal at web dot de
Hi Everyone,
I had the same problem on ubuntu (which is also debian based).
After installing the VirtualBox guest additions that are on the ISO that comes
with VirtualBox instead of the guest additions bundled with debian/ubuntu
solved the issue.
So you just have do install the guest additions on your VM and it should work
fine.
[2011-03-17 10:26:03] gege2061 at homecomputing dot fr
The problem is reproducible with php5.3-201103170730
[2011-03-16 21:13:31] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works perfectly for me. "PHP version: 5.3.5-1" is none of our version numbers.
MAybe your distribution has patched this somehow. Please test our version or
talk to the distributor.
[2011-03-15 15:23:26] gege2061 at homecomputing dot fr
Description:
Hello,
DirectoryIterator is iterable in a while but not in a foreach.
This bug is reproductible only on a vboxsf filesystem. I run this script on
Debian sid hosted on Windows XP (NTFS formated hd).
I have no problem when I execute this script on Windows or on a virtual disk.
Test script:
---
valid()) {
$files[] = (string)$dir->current();
$dir->next();
}
return $files;
}
function test_iterator_bug($dirname) {
$files = array();
$dir = new DirectoryIterator($dirname);
foreach($dir as $file) {
$files[] = (string)$file;
}
return $files;
}
echo 'PHP version: ' . phpversion() . "\n\n";
$dirname = dirname(__FILE__);
foreach (array('iterator', 'iterator_bug') as $test_name) {
echo "--- {$test_name} ---\n";
$foo = "test_{$test_name}";
var_dump($foo($dirname));
echo "\n";
}
Expected result:
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
--- iterator_bug ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
Actual result:
--
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
--- iterator_bug ---
array(0) {
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=54256&edit=1
Req #62257 [Com]: Allow variables in class create
Edit report at https://bugs.php.net/bug.php?id=62257&edit=1
ID: 62257
Comment by: dagguh at gmail dot com
Reported by:valentiny510 at yahoo dot es
Summary:Allow variables in class create
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: XP
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
Absolutely disagreed.
Downvoting this abomination.
Leave creating anonymous classes to mock frameworks
Previous Comments:
[2012-06-13 19:47:54] valentiny510 at yahoo dot es
With the short names was just an example. Imagine one autoload function where
you can create classes on the fly:
(pseudofunction)
function autoload( $class )
{
if ( isset (array($class)))
include/require $class
elseif (file_exists($class))
include $class
else
class $class
{
function __get( $what ){ return $what 'to be / not to be' }
}
}
and I can put here more than 10-20 quick examples...
[2012-06-08 23:37:27] ni...@php.net
If you want to shorten long names make use of the namespacing support
introduced in 5.3. Simply write
use SomeVery\VeryLong\NameAndMore as ShortName;
and you're done. You can also do this programmatically using class_alias().
[2012-06-08 01:20:34] valentiny510 at yahoo dot es
P.S. Not only for long names.. but also for autoloading/extending multiple
classes.. now I let you to imaginate..
[2012-06-08 01:08:33] valentiny510 at yahoo dot es
Description:
I think may be very useful sometimes allowing the use of variables when create
some class like this:
$class = 'test';
class $class { }
Sometimes when working with some cms/framework etc.. they have
a_very_very_very_long_name_for some_classes and will be more easy (depends of
situation) to have an array with shorten name. Ex:
$short_names = array (
'short1' => 'a_very_long_name_of_some_class',
'short2' => 'another_very_long_name');
foreach ($short_names as $short => $long)
class $short extends $long { }
/*endforeach*/;
--
Edit this bug report at https://bugs.php.net/bug.php?id=62257&edit=1
Req #44033 [Opn->Wfx]: make working abstract methods body in abstract classes
Edit report at https://bugs.php.net/bug.php?id=44033&edit=1
ID: 44033
Updated by: ni...@php.net
Reported by:giorgio dot liscio at email dot it
Summary:make working abstract methods body in abstract
classes
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
dagguh has a point. Abstract functions are, well, abstract, so they can't
specify an implementation ^^
Previous Comments:
[2012-10-26 16:02:16] dagguh at gmail dot com
To promote OOD, this issue should be closed as "won't fix"
[2012-10-26 15:59:36] dagguh at gmail dot com
You obviously don't know what abstract methods are about.
Learn OOP, please. This is what you want:
customCheck();
}
protected abstract function customCheck();
}
class Real extends Base
{
protected function customCheck()
{
echo("IT IS WORKING!");
}
}
?>
[2008-02-03 20:33:53] giorgio dot liscio at email dot it
the requested behavior can works with multiple abstract inheritance
abstract class One
{abstract function m(){echo("one ");}}
abstract class Two extends One
{abstract function m(){parent::m();echo("two ");}}
abstract class Three extends Two
{abstract function m(){parent::m();echo("three ");}}
class RealClass extends Three
{
function m(){parent::m();echo("real implementation");}
}
[2008-02-03 18:57:02] giorgio dot liscio at email dot it
Description:
hello
i think can be useful make working abstract methods body in abstract classes
please read carefully ;) i hope you like it
thank you for your time
Reproduce code:
---
Expected result:
echo("WOW ");
echo("IT IS WORKING!");
Actual result:
--
Fatal error: Abstract function Base::commonCheck() cannot contain body
--
Edit this bug report at https://bugs.php.net/bug.php?id=44033&edit=1
Bug #63372 [Opn->Csd]: Namespace Declaration Missing Parse Error
Edit report at https://bugs.php.net/bug.php?id=63372&edit=1
ID: 63372
User updated by:hanskrentel at yahoo dot de
Reported by:hanskrentel at yahoo dot de
Summary:Namespace Declaration Missing Parse Error
-Status: Open
+Status: Closed
Type: Bug
-Package:Class/Object related
+Package:Scripting Engine problem
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
Solved. Thanks NikiC http://stackoverflow.com/a/13094151/367456
Previous Comments:
[2012-10-26 19:15:37] hanskrentel at yahoo dot de
Description:
The following file namespace declaration:
namespace \Name;
Does not give a Parse Error. It's sister declaration:
namespace \Name {}
does.
Test script:
---
https://bugs.php.net/bug.php?id=63372&edit=1
Req #47472 [Com]: Namespaces importing and usage
Edit report at https://bugs.php.net/bug.php?id=47472&edit=1 ID: 47472 Comment by: jeffreytgilbert at gmail dot com Reported by:belliash at gmail dot com Summary:Namespaces importing and usage Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Gentoo Linux PHP Version:5.3.0beta1 Block user comment: N Private report: N New Comment: I'm having the exact same issue. PHP 5.4.7. The Namespace is never imported and can only be used when referencing the full or partial namespace path. This isn't close enough to how the expected functionality would work. This makes partially useless because all existing code that didn't call namespaces directly with their full or partial path referencing classes/methods etc wont work. You can't simply wrap your classes in a namespace and have them encapsulated for easy import where appropriate. Errant code: /* utils_right.php */ /* index.php */ Expected result: I'm using my left hand!I'm using my right hand!I'm using my left hand!I'm using my right hand! Actual result: -- I'm using my left hand!I'm using my right hand! Fatal error: Call to undefined function whichHand() in /home/Belliash/HtDocs/test/index.php on line 9 -- Edit this bug report at https://bugs.php.net/bug.php?id=47472&edit=1
