Re: [PHP-DEV] PHP 4.4.9
Don't you guys have bigger fish to fry? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants!
[PHP-DEV] Re: parent:: forwarding
Hi Etienne,
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static:: and class names don't?
At second, it's too complicated.
I would propose more consistent (from my point of view) and simpler patch.
Each call to static method of parent class (it doesn't mater if it was
done using parent:: or something else) assumes forwarding of called context.
Thanks. Dmitry.
Etienne Kneuss wrote:
Hi,
The patch was made initially by Mike Lively, I adapted it and removed
forward_static_call
http://patches.colder.ch/Zend/lsb_parent_forwarding_53.patch?markup
http://patches.colder.ch/Zend/lsb_parent_forwarding_HEAD.patch?markup
They should merge without trouble.
Regards
Index: Zend/zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.331.2.20.2.24.2.42
diff -u -p -d -r1.331.2.20.2.24.2.42 zend_execute_API.c
--- Zend/zend_execute_API.c 5 Jun 2008 18:50:29 -
1.331.2.20.2.24.2.42
+++ Zend/zend_execute_API.c 8 Jul 2008 11:24:51 -
@@ -1041,8 +1041,15 @@ int zend_call_function(zend_fcall_info *
current_this = EG(This);
current_called_scope = EG(called_scope);
- if (calling_scope) {
- EG(called_scope) = calling_scope;
+
+ if (EX(object)
+ (EX(function_state).function-common.fn_flags ZEND_ACC_STATIC) ==
0) {
+ EG(called_scope) = calling_scope = Z_OBJCE_P(EX(object));
+ } else if (calling_scope) {
+ if (!EG(called_scope) ||
+ !instanceof_function(EG(called_scope), calling_scope
TSRMLS_CC)) {
+ EG(called_scope) = calling_scope;
+ }
} else if (EX(function_state).function-type != ZEND_INTERNAL_FUNCTION)
{
EG(called_scope) = NULL;
}
Index: Zend/zend_vm_def.h
===
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.58
diff -u -p -d -r1.59.2.29.2.48.2.58 zend_vm_def.h
--- Zend/zend_vm_def.h 11 Jun 2008 13:18:39 - 1.59.2.29.2.48.2.58
+++ Zend/zend_vm_def.h 8 Jul 2008 11:24:52 -
@@ -1980,7 +1980,13 @@ ZEND_VM_HANDLER(113, ZEND_INIT_STATIC_ME
EX(fbc) = ce-constructor;
}
- EX(called_scope) = ce;
+ if (EG(called_scope)
+ (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) != 0
+ instanceof_function(EG(called_scope), ce TSRMLS_CC)) {
+ EX(called_scope) = EG(called_scope);
+ } else {
+ EX(called_scope) = ce;
+ }
if (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) {
EX(object) = NULL;
Index: Zend/zend_vm_execute.h
===
RCS file: /repository/ZendEngine2/zend_vm_execute.h,v
retrieving revision 1.62.2.30.2.49.2.58
diff -u -p -d -r1.62.2.30.2.49.2.58 zend_vm_execute.h
--- Zend/zend_vm_execute.h 11 Jun 2008 13:18:39 -
1.62.2.30.2.49.2.58
+++ Zend/zend_vm_execute.h 8 Jul 2008 11:24:54 -
@@ -2613,7 +2613,13 @@ static int ZEND_FASTCALL ZEND_INIT_STAT
EX(fbc) = ce-constructor;
}
- EX(called_scope) = ce;
+ if (EG(called_scope)
+ (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) != 0
+ instanceof_function(EG(called_scope), ce TSRMLS_CC)) {
+ EX(called_scope) = EG(called_scope);
+ } else {
+ EX(called_scope) = ce;
+ }
if (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) {
EX(object) = NULL;
@@ -3186,7 +3192,13 @@ static int ZEND_FASTCALL ZEND_INIT_STAT
EX(fbc) = ce-constructor;
}
- EX(called_scope) = ce;
+ if (EG(called_scope)
+ (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) != 0
+ instanceof_function(EG(called_scope), ce TSRMLS_CC)) {
+ EX(called_scope) = EG(called_scope);
+ } else {
+ EX(called_scope) = ce;
+ }
if (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) {
EX(object) = NULL;
@@ -3654,7 +3666,13 @@ static int ZEND_FASTCALL ZEND_INIT_STAT
EX(fbc) = ce-constructor;
}
- EX(called_scope) = ce;
+ if (EG(called_scope)
+ (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) != 0
+ instanceof_function(EG(called_scope), ce TSRMLS_CC)) {
+ EX(called_scope) = EG(called_scope);
+ } else {
+ EX(called_scope) = ce;
+ }
if (EX(fbc)-common.fn_flags ZEND_ACC_STATIC) {
EX(object) = NULL;
@@ -3878,7 +3896,13 @@ static int ZEND_FASTCALL ZEND_INIT_STAT
EX(fbc) = ce-constructor;
}
- EX(called_scope) = ce;
+ if (EG(called_scope)
+ (EX(fbc)-common.fn_flags
Re: [PHP-DEV] Re: parent:: forwarding
On Tue, 8 Jul 2008, Dmitry Stogov wrote: I took a look into the patch and I don't like it all. At first, I don't see any consistency there. Why parent:: does forwarding but self::, static:: and class names don't? At second, it's too complicated. I would propose more consistent (from my point of view) and simpler patch. Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. That sounds like a massive BC break to me, as that's not what happens now. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
5.2 didn't have static:: so it cannot be a BC break. Thanks. Dmitry. Derick Rethans wrote: On Tue, 8 Jul 2008, Dmitry Stogov wrote: I took a look into the patch and I don't like it all. At first, I don't see any consistency there. Why parent:: does forwarding but self::, static:: and class names don't? At second, it's too complicated. I would propose more consistent (from my point of view) and simpler patch. Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. That sounds like a massive BC break to me, as that's not what happens now. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
On Tue, Jul 8, 2008 at 3:39 PM, Dmitry Stogov [EMAIL PROTECTED] wrote: I took a look into the patch and I don't like it all. At first, I don't see any consistency there. Why parent:: does forwarding but self::, static:: and class names don't? class names don't because, people expect their results to be context-independent. It is just a call of some method on some class. parent, on the other hand, implies inheritance. self and static should do forwarding too, I think, because they are context-dependent by design. forwardind is expected here At second, it's too complicated. I would propose more consistent (from my point of view) and simpler patch. Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. Thanks. Dmitry. Etienne Kneuss wrote: Hi, The patch was made initially by Mike Lively, I adapted it and removed forward_static_call http://patches.colder.ch/Zend/lsb_parent_forwarding_53.patch?markup http://patches.colder.ch/Zend/lsb_parent_forwarding_HEAD.patch?markup They should merge without trouble. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Class names are already context-dependent.
?php
class Foo {
function test() {
var_dump($this);
}
}
class Bar extends Foo {
function test() {
Foo::test(); /* this is a dynamic method call */
}
}
$x = new Bar();
$x-test();
?
Thanks. Dmitry.
Alexey Zakhlestin wrote:
On Tue, Jul 8, 2008 at 3:39 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static:: and class names don't?
class names don't because, people expect their results to be
context-independent. It is just a call of some method on some
class.
parent, on the other hand, implies inheritance. self and static
should do forwarding too, I think, because they are context-dependent
by design. forwardind is expected here
At second, it's too complicated.
I would propose more consistent (from my point of view) and simpler patch.
Each call to static method of parent class (it doesn't mater if it was
done using parent:: or something else) assumes forwarding of called context.
Thanks. Dmitry.
Etienne Kneuss wrote:
Hi,
The patch was made initially by Mike Lively, I adapted it and removed
forward_static_call
http://patches.colder.ch/Zend/lsb_parent_forwarding_53.patch?markup
http://patches.colder.ch/Zend/lsb_parent_forwarding_HEAD.patch?markup
They should merge without trouble.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: parent:: forwarding
-- Forwarded message -- From: Mike Lively [EMAIL PROTECTED] Date: Tue, Jul 8, 2008 at 6:23 AM Subject: Re: [PHP-DEV] Re: parent:: forwarding To: Dmitry Stogov [EMAIL PROTECTED] On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov [EMAIL PROTECTED] wrote: Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. Isn't this what the original LSB patches did and it was determined that letting everything forward was a bad idea? http://marc.info/?l=php-internalsm=118995456612295w=2 The idea now is that we need a combination. static class names don't forward called context but parent:: does. If I could only choose between always forwarding called context and never forwarding called context (for parent:: and class names) I would rather always forward so this wouldn't be the end of the world for me, but I do believe the mixture is a more flexible way of handling things. On a different note, is that functionality introduced by the patch you don't like or is it the specific implementation? Is there a better way to implement it and retain the functionality it introduces? (for my own benefit) -Mike Lively
[PHP-DEV] [PATCH] RecursiveTreeIterator implementation
Hi, I have seen a NEEDS DEVELOPER flag on the TODO for the Implement RecursiveTreeIterator in C task, so I would like to propose my implementation [1]. Currently it follows the PHP implementation, except that it does not have a $prefix public property (how about a private property and a setter method ?). I hope this patch will be useful. Please say me if anything is wrong with it. [1] http://arnaud.lb.s3.amazonaws.com/RecursiveTreeIterator.patch [2] http://arnaud.lb.s3.amazonaws.com/RecursiveTreeIterator-phpt.tar.bz2 Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hi Mike, Yes. It was the initial proposal that was quite consistent. With current proposal we can call the same static method from the same context with different behavior parent::foo(), self::foo(), A::foo(). I didn't get why can I call parent's method, but cannot call self or grand-parent's method (with the same behavior). Thanks. Dmitry. Mike Lively wrote: -- Forwarded message -- From: Mike Lively [EMAIL PROTECTED] Date: Tue, Jul 8, 2008 at 6:23 AM Subject: Re: [PHP-DEV] Re: parent:: forwarding To: Dmitry Stogov [EMAIL PROTECTED] On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov [EMAIL PROTECTED] wrote: Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. Isn't this what the original LSB patches did and it was determined that letting everything forward was a bad idea? http://marc.info/?l=php-internalsm=118995456612295w=2 The idea now is that we need a combination. static class names don't forward called context but parent:: does. If I could only choose between always forwarding called context and never forwarding called context (for parent:: and class names) I would rather always forward so this wouldn't be the end of the world for me, but I do believe the mixture is a more flexible way of handling things. On a different note, is that functionality introduced by the patch you don't like or is it the specific implementation? Is there a better way to implement it and retain the functionality it introduces? (for my own benefit) -Mike Lively -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith: 1) intl extension Last discussion ended without a decision on the class naming [10]. I specifically remember Derick taking issue with intl ext invading the date ext namespace. Stas however arguing that the intl ext is supposed to bring some forwards compatibility to PHP 6 and therefore naturally will need to span the namespaces of other extensions, that are planned to be expanded for PHP 6. Well... we had some discussions on the i18n list, and everyone except Stas said we should have consistent class prefixes. That did not stop Stas from simply rolling a final, stable 1.0.0. Even though I and others pointed out other problems with it, where fixing them will break BC. Very unfortunate, this... David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith: 1) intl extension Last discussion ended without a decision on the class naming [10]. I specifically remember Derick taking issue with intl ext invading the date ext namespace. Stas however arguing that the intl ext is supposed to bring some forwards compatibility to PHP 6 and therefore naturally will need to span the namespaces of other extensions, that are planned to be expanded for PHP 6. Well... we had some discussions on the i18n list, and everyone except Stas said we should have consistent class prefixes. That did not stop Stas from simply rolling a final, stable 1.0.0. Even though I and others pointed out other problems with it, where fixing them will break BC. Very unfortunate, this... David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Mail Server Configuration
Just a quick note to whomever did the mail server configuration: After a [enhancement pill name here] SPAM message from me (not really, but you know what I mean) hit the Internals list and bounced back, I saw the 550. 550: we're manly enough already Nice. That made my morning. ;-P -- /Daniel P. Brown Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just $59.99/mo. with no contract! Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hi, I wouldn't mind if we weighted the pros/cons of the current solution against the initial proposition now that we had nearly 1 year to experience with the way it is now. I really feel that the current way is something that we will regret later. And as of which solution to adopt, either always-forward or parent::/self:: forward, I believe they're both acceptable. Regards On Tue, Jul 8, 2008 at 4:17 PM, Dmitry Stogov [EMAIL PROTECTED] wrote: Hi Mike, Yes. It was the initial proposal that was quite consistent. With current proposal we can call the same static method from the same context with different behavior parent::foo(), self::foo(), A::foo(). I didn't get why can I call parent's method, but cannot call self or grand-parent's method (with the same behavior). Thanks. Dmitry. Mike Lively wrote: -- Forwarded message -- From: Mike Lively [EMAIL PROTECTED] Date: Tue, Jul 8, 2008 at 6:23 AM Subject: Re: [PHP-DEV] Re: parent:: forwarding To: Dmitry Stogov [EMAIL PROTECTED] On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov [EMAIL PROTECTED] wrote: Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. Isn't this what the original LSB patches did and it was determined that letting everything forward was a bad idea? http://marc.info/?l=php-internalsm=118995456612295w=2 The idea now is that we need a combination. static class names don't forward called context but parent:: does. If I could only choose between always forwarding called context and never forwarding called context (for parent:: and class names) I would rather always forward so this wouldn't be the end of the world for me, but I do believe the mixture is a more flexible way of handling things. On a different note, is that functionality introduced by the patch you don't like or is it the specific implementation? Is there a better way to implement it and retain the functionality it introduces? (for my own benefit) -Mike Lively -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] ext/date tzinfo structure references
The result of calling getTimezone() on a Date object results in a
DateTimeZone object with a reference to the dateobj-time-tz_info
object which may get later destroyed.
This can cause unexpected script behaviour or interpreter crashes, test
case in attachment (1).
When I fixed this the obvious way, per attachment 3, by adding a clone,
I wondered where the cloned tzinfo structures would get destroyed and I
can't see anywhere.
After looking at this further - so far as I can tell, the duplication of
the tzinfo structures throughout this code is not actually necessary;
when the structures are created they are referenced from the global
tzcache and will hence last forever anyway. The structures are not
changed anywhere either, again AFAICT; though they aren't treated as
const so maybe I'm missing something there.
So simply copying pointers around would simplify the code, fix leaks and
fix the bug as well. That's attachment (2).
What do you think?
Regards, Joe
Index: ext/date/tests/015.phpt
===
RCS file: ext/date/tests/015.phpt
diff -N ext/date/tests/015.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ext/date/tests/015.phpt 8 Jul 2008 14:35:51 -
@@ -0,0 +1,22 @@
+--TEST--
+timezone object reference handling
+--INI--
+date.timezone=UTC
+--FILE--
+?php
+$dto = new DateTime();
+$tzold = $dto-getTimezone();
+var_dump($tzold-getName());
+$dto-setTimezone(new DateTimeZone('US/Eastern'));
+var_dump($tzold-getName());
+var_dump($dto-getTimezone()-getName());
+unset($dto);
+var_dump($tzold-getName());
+echo Done\n;
+?
+--EXPECTF--
+unicode(3) UTC
+unicode(3) UTC
+unicode(10) US/Eastern
+unicode(3) UTC
+Done
Index: ext/date/php_date.c
===
RCS file: /repository/php-src/ext/date/php_date.c,v
retrieving revision 1.189
diff -u -r1.189 php_date.c
--- ext/date/php_date.c 7 Jun 2008 22:41:02 - 1.189
+++ ext/date/php_date.c 8 Jul 2008 14:21:35 -
@@ -1341,14 +1341,6 @@
timelib_update_ts(t, tzi);
ts = timelib_date_to_int(t, error2);
- /* if tz_info is not a copy, avoid double free */
- if (now-tz_info != tzi now-tz_info) {
- timelib_tzinfo_dtor(now-tz_info);
- }
- if (t-tz_info != tzi) {
- timelib_tzinfo_dtor(t-tz_info);
- }
-
timelib_time_dtor(now);
timelib_time_dtor(t);
@@ -1779,7 +1771,7 @@
newdateobj-time-tz_abbr = strdup(it_time-tz_abbr);
}
if (it_time-tz_info) {
- newdateobj-time-tz_info =
timelib_tzinfo_clone(it_time-tz_info);
+ newdateobj-time-tz_info = it_time-tz_info;
}
*data = iterator-current;
@@ -1966,7 +1958,7 @@
new_obj-time-tz_abbr = strdup(old_obj-time-tz_abbr);
}
if (old_obj-time-tz_info) {
- new_obj-time-tz_info =
timelib_tzinfo_clone(old_obj-time-tz_info);
+ new_obj-time-tz_info = old_obj-time-tz_info;
}
return new_ov;
@@ -2185,9 +2177,6 @@
php_date_obj *intern = (php_date_obj *)object;
if (intern-time) {
- if (intern-time-tz_info) {
- timelib_tzinfo_dtor(intern-time-tz_info);
- }
timelib_time_dtor(intern-time);
}
@@ -2220,16 +2209,10 @@
php_period_obj *intern = (php_period_obj *)object;
if (intern-start) {
- if (intern-start-tz_info) {
- timelib_tzinfo_dtor(intern-start-tz_info);
- }
timelib_time_dtor(intern-start);
}
if (intern-end) {
- if (intern-end-tz_info) {
- timelib_tzinfo_dtor(intern-end-tz_info);
- }
timelib_time_dtor(intern-end);
}
@@ -2268,14 +2251,11 @@
timelib_time *now;
timelib_tzinfo *tzi;
timelib_error_container *err = NULL;
- int free_tzi = 0, type = TIMELIB_ZONETYPE_ID, new_dst;
+ int type = TIMELIB_ZONETYPE_ID, new_dst;
char *new_abbr;
timelib_sll new_offset;
if (dateobj-time) {
- if (dateobj-time-tz_info) {
- timelib_tzinfo_dtor(dateobj-time-tz_info);
- }
timelib_time_dtor(dateobj-time);
}
if (format) {
@@ -2303,8 +2283,7 @@
tzobj = (php_timezone_obj *)
zend_object_store_get_object(timezone_object TSRMLS_CC);
switch (tzobj-type) {
case TIMELIB_ZONETYPE_ID:
- tzi = timelib_tzinfo_clone(tzobj-tzi.tz);
- free_tzi = 1;
+ tzi = tzobj-tzi.tz;
break;
case TIMELIB_ZONETYPE_OFFSET:
new_offset = tzobj-tzi.utc_offset;
Re: [PHP-DEV] [PATCH] ext/date tzinfo structure references
On Tue, 8 Jul 2008, Joe Orton wrote: The result of calling getTimezone() on a Date object results in a DateTimeZone object with a reference to the dateobj-time-tz_info object which may get later destroyed. This can cause unexpected script behaviour or interpreter crashes, test case in attachment (1). When I fixed this the obvious way, per attachment 3, by adding a clone, I wondered where the cloned tzinfo structures would get destroyed and I can't see anywhere. After looking at this further - so far as I can tell, the duplication of the tzinfo structures throughout this code is not actually necessary; when the structures are created they are referenced from the global tzcache and will hence last forever anyway. The structures are not changed anywhere either, again AFAICT; though they aren't treated as const so maybe I'm missing something there. So simply copying pointers around would simplify the code, fix leaks and fix the bug as well. That's attachment (2). What do you think? Sounds sane... I was going to have a look at this tonight and do something similar - this saves some work. I'll see if it fixes all leaks, and commit it if it works fine. Thanks for the patch. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] re2c issues? (Was Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_language_scanner.l)
Hi Nuno, all,
I didn't test it, but yeah that should fix the # problem. :-) BTW, I also
had other ideas about checking for ?, %, script, etc. tags in the inline
HTML scanning part, so the largest chunk of HTML is always grabbed (I'll
send the patch in the future; didn't modify anything yet, and it's not
related to the subject anyway :-)).
Still wondering about the behavior of re2c at EOF being different than
Flex -- can't re2c have an addition/enhancement that simply keeps track of
the rule that *would have* matched before hitting EOF (e.g. YYCURSOR =
YYLIMIT) and then jump to it when doing the YYFILL check?
Another thing that isn't working is the warning about /* Unterminated
comments... (never seen). The optimization for comment parsing I was going
to do (along with the above HTML stuff) would also work around that -- not
using re2c rules, but a manual scan or zend_memnstr() for the closing */.
Like I said in the comments for Bug #45372, if the last thing at the end of
a file is matched by a variable length rule, it will not be returned.
Because of
#define YYFILL(n) { if (YYCURSOR = YYLIMIT) return 0; }
I put the ? in the subject line because I'm not sure how important this
really is, but it just seems broken to me (though it's usually with invalid
code), and I couldn't think of a workaround with my limited knowledge of
re2c (though I think it would need to be changed internally). Some things
this affects are 1) the tokenizer extension -- the last token won't be
returned (if variable length, of course); 2) highlighting (if someone is
trying to see an unclosed string error, for example? PHP highlighting on
forums...), and parse errors can be different than previously if the parser
gets one less token, for example:
$foo = Unclosed stringnewline // Different error line number; I think
the space before the quote is the last token returned (even w/o newline)
function test // *Nothing* after test, used to say expecting '(', now says
expecting T_STRING; again, space before test is the last token
function test()
OR
array
at the end of a file work the same still because ) and array are fixed
length matches... Or, add a few newlines at the end and they won't be
counted, etc.
It's been awhile since I checked out the details, so I can't recall at the
moment if there are more serious examples. Also not sure if some of this is
affecting the ini scanner (see Bug #45384), as I haven't really look at its
code.
What are everyone's thoughts...?
- Matt
- Original Message -
From: Nuno Lopes
Sent: Tuesday, July 08, 2008
nlopess Tue Jul 8 15:16:35 2008 UTC
Modified files: (Branch: PHP_5_3)
/ZendEngine2 zend_language_scanner.l
Log:
now really fix once and for all the #-style comments.
also remove some duplicated code in ?, %, %= handlers. this also has
the side-effect of producing better bytecodes in some special cases
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_language_scanner.l?r1=1.131.2.11.2.13.2.21r2=1.131.2.11.2.13.2.22diff_format=u
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Hi! Well... we had some discussions on the i18n list, and everyone except Stas said we should have consistent class prefixes. Everyone being you and one other person, and except being all people actually working on the extension. Anyway, I don't want to start another round of bikeshedding so I leave it in RMs hands - if RMs decide it should be changed we change it, even though I think it'd be a mistake. If you want me to explain again why this way was chosen - I can. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: parent:: forwarding
Hi! Each call to static method of parent class (it doesn't mater if it was done using parent:: or something else) assumes forwarding of called context. That would make it impossible to do non-forwarding call. Which means you can't use something like ActiveRecord pattern (which uses LSB) inside the context of another method that uses LSB too. I.e. if you got the called_scope set once, you are stuck with it forever until the topmost call ends, and you can not make another (new) LSB call inside that method. I don't think it is a good idea. It would lead to massive WTFs when you have code that perfectly working in unit tests (when you call it independently without called_scope pre-set) but breaks as soon as you call it with called_scope set (since all static calls like Foo::bar() would instantly start forwarding pre-set called_scope instead of creating a new one). If this is the way it would work, I'd recommend never using this feature - you just can't know what your Foo:: would produce anymore, since the start of the call chain can be anywhere and there's no method to ensure you get the actual class that you used in the call. Which as far as I remember was the whole point behind LSB, but somehow it is lost now. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hi! With current proposal we can call the same static method from the same context with different behavior parent::foo(), self::foo(), A::foo(). That's exactly what I said when I explained why I didn't like the idea of chainging parent::. I was told I am the only one that doesn't like parent:: to be different and everybody else just loves it to be different. Well... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Just a quick reminder at Johannes and I were looking for feedback by July 9th (aka tomorrow) .. On 02.07.2008, at 22:00, Lukas Kahwe Smith wrote: snip Summary: Everybody review [1] and make sure all items you care about are on the list and your name only appears next to stuff you are actually able to complete in a timely manner. snip [1] http://wiki.php.net/todo/php53 regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
Hi Johannes,
thanks for the patch, next to platform specific stuff I'm wondering
whether the shutdown order is right:
[..snip..]
Destructors can be PHP code, as can some ob callback so I think the order
should be changed.
Yes, great catch, the order is incorrect. We use a different order
internally that didn¹t translate properly when I merged to php 5.3. My goal
is to have the unset be as high as possible in the shutdown after all
possible userspace code is executed as well as response is sent but before
any real executor teardown starts happening. I¹ve updated the patch attached
to the rfc which moves the timeout unset in php_request_shutdown from #2,
after php_call_shutdown_functions to #5, after sapi_send_headers. Does this
seem better?
/* 4. Send the set HTTP headers (note: This must be done AFTER
php_end_ob_buffers() !!) */
zend_try {
sapi_send_headers(TSRMLS_C);
} zend_end_try();
/* 5. Reset max_execution_time (no longer executing php code after response
sent) */
zend_try {
zend_unset_timeout(TSRMLS_C);
} zend_end_try();
/* 6. Call all extensions RSHUTDOWN functions */
if (PG(modules_activated)) {
zend_deactivate_modules(TSRMLS_C);
php_free_shutdown_functions(TSRMLS_C);
}
-lucas
