Req #41856 [Com]: support for anonymous classes
Edit report at https://bugs.php.net/bug.php?id=41856&edit=1
ID: 41856
Comment by: krak...@php.net
Reported by:mbaynton at gmail dot com
Summary:support for anonymous classes
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
http://wiki.php.net/rfc/anonymous_classes
Previous Comments:
[2013-09-02 22:06:30] johan...@php.net
My guess is that anonymous classes would have a good chance once a good
implementation comes by. This is not completely trivial as the class_entry has
to be stored in the class_table but has to be somewhat hidden and we might have
to find a way to hide the information in the oparray.
As all things in PHP this needs a volunteer to do it. All contributors have
sometime X to work on PHP and in time X can either discuss stuff, fix bugs or
implement features ... but with some guidance this might be a nice project for
a newcomer (I'd volunteer to give a hand to point in the right direction etc.,
while this guarantees acceptance in no way as that would need an RFC etc.)
until then we have to live with workarounds.
For the PageController interface example an (work-around) alternative is
$page_controller = [
'get' => function () {},
'post' => function () {}
};
[2013-09-02 21:42:36] zatacorothx at gmail dot com
Anonymous classes in Java are convenient when used with Interfaces. In PHP,
this
could help with MVC frameworks. Say all pages had a class that implemented
PageController:
[some_page.php]
$page_controller = new PageInterface() {
function doGet() {}
function doPost() {}
};
A current workaround would be using a factory or constructor to which you pass
required methods, and not using an interface. It works, but then you have to
deal with missing methods in application logic where you could otherwise just
handle an error.
[2013-07-22 15:32:27] pacerier at gmail dot com
+1
[2012-03-15 18:45:47] paj...@php.net
Not exactly the same but look at closure and traits support in 5.4.
[2012-03-15 18:35:55] david71rj at gmail dot com
+1
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=41856
--
Edit this bug report at https://bugs.php.net/bug.php?id=41856&edit=1
Bug #64490 [PATCH]: struct flock undefined on FreeBSD
Edit report at https://bugs.php.net/bug.php?id=64490&edit=1 ID: 64490 Patch added by: krak...@php.net Reported by:ond...@php.net Summary:struct flock undefined on FreeBSD Status: Open Type: Bug Package:Compile Failure Operating System: GNU kFreeBSD PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: kfbsd.preprocessor Revision: 1363975574 URL: https://bugs.php.net/patch-display.php?bug=64490&patch=kfbsd.preprocessor&revision=1363975574 Previous Comments: [2013-03-22 12:32:47] ond...@php.net Description: Zend OpCache doesn't build on Debian GNU/kFreeBSD (amd64). Full build log: https://buildd.debian.org/status/fetch.php?pkg=php5&arch=kfreebsd- amd64&ver=5.5.0~beta1-1&stamp=1363952343 Expected result: PHP built Actual result: -- /bin/bash /build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/cli-build/libtool --preserve-dup-deps --mode=compile x86_64- kfreebsd-gnu-gcc -Iext/opcache/ -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd- amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/ -DPHP_ATOM_INC -I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/include - I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli- build/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1 -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/cli-build/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd- amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1- kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/ereg/regex -I/usr/include/libxml2 - I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/ext/mbstring/libmbfl -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd- amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl -I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/ext/mbstring/libmbfl/mbfl -I/build/buildd-php5_5.5.0~beta1-1- kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl/mbfl - I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli- build/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/cli-build/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64- MDnVFk/php5-5.5.0~beta1/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64- MDnVFk/php5-5.5.0~beta1/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64- MDnVFk/php5-5.5.0~beta1/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64- MDnVFk/php5-5.5.0~beta1/cli-build/-I/usr/include -O2 -Wall -fsigned-char - fno-strict-aliasing -gstabs -fvisibility=hidden -prefer-pic -c /build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/ext/opcache/ZendAccelerator.c -o ext/opcache/ZendAccelerator.lo libtool: compile: x86_64-kfreebsd-gnu-gcc -Iext/opcache/ "-I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/" - DPHP_ATOM_INC "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/cli-build/include" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd- amd64-MDnVFk/php5-5.5.0~beta1/cli-build/main" "-I/build/buildd-php5_5.5.0~beta1- 1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1" "-I/build/buildd-php5_5.5.0~beta1-1- kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/date/lib" "-I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib" "- I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5- 5.5.0~beta1/ext/ereg/regex" -I/usr/include/libxml2 "-I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli- build/ext/mbstring/libmbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64- MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl/mbfl" "-I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli- build/ext/mbstring/libmbfl/mbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd- amd64-MDnVFk/php5-5.5.0~beta1/cli-build/TSRM" "-I/build/buildd-php5_5.5.0~beta1- 1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/Zend" "-I/build/buildd- php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/main" "- I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/Zend" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/TSRM" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli- build/" -I/usr/include -O2 -Wall -fsigned-char -fno-strict-al
Bug #64485 [Com]: Issue in Configuring 32bit PHP5.3.22 in RHEL 6.0
Edit report at https://bugs.php.net/bug.php?id=64485&edit=1 ID: 64485 Comment by: krak...@php.net Reported by:viswanathan dot saravanan at wipro dot com Summary:Issue in Configuring 32bit PHP5.3.22 in RHEL 6.0 Status: Open Type: Bug Package:*Configuration Issues Operating System: RHEL 6.2 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Have you tried --with-libdir=lib and or --libdir=/usr/lib ? Previous Comments: [2013-03-22 07:57:12] viswanathan dot saravanan at wipro dot com Description: Am trying to Configure 32bit PHP5.3.22 in RHEL 6.0 but its throwing the below error checking libxml2 install dir... no checking for xml2-config path... /usr/bin/xml2-config checking whether libxml build works... no configure: error: build test failed. where we have already installed libxml2.x86_64 2.7.6-4.el6_2.1@tsl-620-rhel-x86_64-server-6 libxml2-devel.x86_642.7.6-4.el6_2.1@tsl-620-rhel-x86_64-server-6 libxml2-python.x86_64 2.7.6-4.el6_2.1@tsl-620-rhel-x86_64-server-6 libxml2.i6862.7.6-4.el6_2.1tsl-620-rhel-x86_64-server-6 libxml2-devel.i686 2.7.6-4.el6_2.1tsl-620-rhel-x86_64-server-6 zlib.i686 1.2.3-27.el6 @tsl-620-rhel-x86_64-server-6 zlib.x86_64 1.2.3-27.el6 @anaconda- RedHatEnterpriseLinux-20171049.x86_64/6.2 zlib-devel.x86_64 1.2.3-27.el6 @tsl-620-rhel-x86_64-server-6 jzlib.x86_641.0.7-7.5.el6 tsl-620-rhel-x86_64-server-6 zlib-devel.i686 1.2.3-27.el6 tsl-620-rhel-x86_64-server-6 we have all the 32 bit files in /usr/lib/ libxml2.so.2 ,libz.so.1 files also but still its showing error in configuring. -- Edit this bug report at https://bugs.php.net/bug.php?id=64485&edit=1
Req #64639 [PATCH]: Add third parameter to nl2br
Edit report at https://bugs.php.net/bug.php?id=64639&edit=1
ID: 64639
Patch added by: krak...@php.net
Reported by:valentiny510 at yahoo dot es
Summary:Add third parameter to nl2br
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: nl2br_additional_parameter
Revision: 1366227875
URL:
https://bugs.php.net/patch-display.php?bug=64639&patch=nl2br_additional_parameter&revision=1366227875
Previous Comments:
[2013-04-12 02:12:27] valentiny510 at yahoo dot es
Description:
The name "nl2br" for somebody who doesn't know php very well, suggest that
actually replace "nl" with "br" but is not true. The name of the function
function should be "nl2nl+br"
I think it should have a third parameter like $replace, and actually Replace
the nl with br
I have some clients who used this function inside pre with horrible result.
Anyway, I think it will be more usefull this
nl2br ($string, true/false, $replace = true/false)
than
preg_replace('#([\r?\n]+)#', '', $string) or
str_replace(array("\r\n", "\r", "\n"), '', $string)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64639&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
Previous Comments:
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
Previous Comments:
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356954599
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356954599
Previous Comments:
[2012-12-31 11:37:55] krak...@php.net
-2 will provide get_calling_method and get_calling_class, I think that's
everything you should need
[2012-12-31 11:36:48] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
----
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
----
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Bug #64046 [Com]: Segmentation fault in pcre library
Edit report at https://bugs.php.net/bug.php?id=64046&edit=1 ID: 64046 Comment by: krak...@php.net Reported by:public at miholeus dot com Summary:Segmentation fault in pcre library Status: Open Type: Bug Package:PCRE related Operating System: Ubuntu 12.04.1 LTS PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This does cause a stack overflow, for some reason the default limits for recursion are very high, maybe someone has an explanation of that. You have: "/'([^'])*'/" Shouldn't that be: "/'([^']*)'/" ? Previous Comments: [2013-01-22 13:47:19] public at miholeus dot com Description: The following code causes segmentation fault. You can see the code by link I've provided. Test script: --- Code http://pastebin.com/UzBjDaZU Expected result: no segfault Actual result: -- With gdb: (gdb) run /var/www/work/crm/trunk/pcre.php Starting program: /usr/bin/php /var/www/work/crm/trunk/pcre.php [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe42e4700 (LWP 4329)] [Thread 0x7fffe42e4700 (LWP 4329) exited] Program received signal SIGSEGV, Segmentation fault. 0x76d99a62 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3 -- Edit this bug report at https://bugs.php.net/bug.php?id=64046&edit=1
[PHP-BUG] Bug #64196 [NEW]: __clone recursion stack overflow
From: krak...@php.net Operating system: Any PHP version: Irrelevant Package: Reproducible crash Bug Type: Bug Bug description:__clone recursion stack overflow Description: This patch avoids stack overflows where recursion is present in __clone. Test script: --- Expected result: Stack overflow Actual result: -- E_ERROR -- Edit bug report at https://bugs.php.net/bug.php?id=64196&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64196&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64196&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64196&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64196&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64196&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64196&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64196&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64196&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64196&r=support Expected behavior: https://bugs.php.net/fix.php?id=64196&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64196&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64196&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64196&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64196&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64196&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64196&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64196&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64196&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64196&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64196&r=mysqlcfg
Bug #64196 [PATCH]: __clone recursion stack overflow
Edit report at https://bugs.php.net/bug.php?id=64196&edit=1 ID: 64196 Patch added by: krak...@php.net Reported by:krak...@php.net Summary:__clone recursion stack overflow Status: Open Type: Bug Package:Reproducible crash Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: __clone-2.patch Revision: 1360699422 URL: https://bugs.php.net/patch-display.php?bug=64196&patch=__clone-2.patch&revision=1360699422 Previous Comments: [2013-02-12 14:45:15] ni...@php.net zend_object.guards is for property guards. Wouldn't you be clashing with the guard for $__clone here? Also, I'm not convinced we need to add this check at all. Recursion is a valid means of programming and as long as there is some termination condition everything's okay. Arguably with "clone" recursion makes rather little sense, but as it stands now we are open to recursion everywhere and I don't think we should go down the patch of saying "recursion is okay here, but it's not okay here". I mean, "include" for example can also be used recursively, even though you might argue that that's nearly as useless. Should we be adding checks everywhere, where we think recursion makes too little sense? I don't think so. The only (calls) that currently use recursion guarding are __get/__set and friends. For those it makes sense because the recursion guarding gives access to the underlying property, so it has some actual function (rather than just forbidding a programming pattern). -------- [2013-02-12 14:27:47] krak...@php.net Description: This patch avoids stack overflows where recursion is present in __clone. Test script: --- Expected result: Stack overflow Actual result: -- E_ERROR -- Edit this bug report at https://bugs.php.net/bug.php?id=64196&edit=1
Bug #64196 [Com]: __clone recursion stack overflow
Edit report at https://bugs.php.net/bug.php?id=64196&edit=1 ID: 64196 Comment by: krak...@php.net Reported by:krak...@php.net Summary:__clone recursion stack overflow Status: Open Type: Bug Package:Reproducible crash Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: __clone-2.patch addresses the clash ... and ensures proper functionality in all situations, not just basic examples. we don't seem to be able to agree on whether such checks should be made, but at least now there are no clashes and the patch is correct ... Previous Comments: [2013-02-12 20:03:42] krak...@php.net The following patch has been added/updated: Patch Name: __clone-2.patch Revision: 1360699422 URL: https://bugs.php.net/patch-display.php?bug=64196&patch=__clone-2.patch&revision=1360699422 [2013-02-12 14:45:15] ni...@php.net zend_object.guards is for property guards. Wouldn't you be clashing with the guard for $__clone here? Also, I'm not convinced we need to add this check at all. Recursion is a valid means of programming and as long as there is some termination condition everything's okay. Arguably with "clone" recursion makes rather little sense, but as it stands now we are open to recursion everywhere and I don't think we should go down the patch of saying "recursion is okay here, but it's not okay here". I mean, "include" for example can also be used recursively, even though you might argue that that's nearly as useless. Should we be adding checks everywhere, where we think recursion makes too little sense? I don't think so. The only (calls) that currently use recursion guarding are __get/__set and friends. For those it makes sense because the recursion guarding gives access to the underlying property, so it has some actual function (rather than just forbidding a programming pattern). ---- [2013-02-12 14:27:47] krak...@php.net Description: This patch avoids stack overflows where recursion is present in __clone. Test script: --- Expected result: Stack overflow Actual result: -- E_ERROR -- Edit this bug report at https://bugs.php.net/bug.php?id=64196&edit=1
Bug #64196 [PATCH]: __clone recursion stack overflow
Edit report at https://bugs.php.net/bug.php?id=64196&edit=1
ID: 64196
Patch added by: krak...@php.net
Reported by:krak...@php.net
Summary:__clone recursion stack overflow
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: __clone-2.patch
Revision: 1360710727
URL:
https://bugs.php.net/patch-display.php?bug=64196&patch=__clone-2.patch&revision=1360710727
Previous Comments:
[2013-02-12 21:39:24] ni...@php.net
Not sure in what way the new patch resolves the clash. Doesn't it just move it
from "$foo->__clone" towards "$foo->{'$__clone'}"?
--------
[2013-02-12 20:05:02] krak...@php.net
__clone-2.patch addresses the clash ... and ensures proper functionality in all
situations, not just basic examples.
we don't seem to be able to agree on whether such checks should be made, but at
least now there are no clashes and the patch is correct ...
----
[2013-02-12 20:03:42] krak...@php.net
The following patch has been added/updated:
Patch Name: __clone-2.patch
Revision: 1360699422
URL:
https://bugs.php.net/patch-display.php?bug=64196&patch=__clone-2.patch&revision=1360699422
[2013-02-12 14:45:15] ni...@php.net
zend_object.guards is for property guards. Wouldn't you be clashing with the
guard for $__clone here?
Also, I'm not convinced we need to add this check at all. Recursion is a valid
means of programming and as long as there is some termination condition
everything's okay. Arguably with "clone" recursion makes rather little sense,
but as it stands now we are open to recursion everywhere and I don't think we
should go down the patch of saying "recursion is okay here, but it's not okay
here". I mean, "include" for example can also be used recursively, even though
you might argue that that's nearly as useless. Should we be adding checks
everywhere, where we think recursion makes too little sense? I don't think so.
The only (calls) that currently use recursion guarding are __get/__set and
friends. For those it makes sense because the recursion guarding gives access
to the underlying property, so it has some actual function (rather than just
forbidding a programming pattern).
[2013-02-12 14:27:47] krak...@php.net
Description:
This patch avoids stack overflows where recursion is present in __clone.
Test script:
---
Expected result:
Stack overflow
Actual result:
--
E_ERROR
--
Edit this bug report at https://bugs.php.net/bug.php?id=64196&edit=1
