Re: [PHP-DEV] Dropping ze1_compatibility_mode (PHP 5.3)
2008/3/10, Felipe Pena [EMAIL PROTECTED]: Hello! I've backported the Dmitry's patch (HEAD) for to drop zend.ze1_compatibility_mode in PHP_5_3 branch. Would be interesting remove it in 5_3? :) +1 , because this feature does not work, so there is no point to keep it anymore. -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
RE: [PHP-DEV] Patch for opcode caches
Hi Marcus,
I've just rechecked the -e option, and it works fine for me.
I'm wonderwed why (and how) it didn't work for you.
I hope I already answered your questions and you see the needness of
this patch.
So I hope you agree that I'll commit it tomorrow (with comments about
compiler options)
Thanks. Dmitry.
-Original Message-
From: Dmitry Stogov
Sent: Monday, March 10, 2008 3:48 PM
To: 'Marcus Boerger'
Cc: Andi Gutmans; Stas Malyshev; 'phpxcache';
'internals@lists.php.net'
Subject: RE: [PHP-DEV] Patch for opcode caches
Hi Marcus,
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09, 2008 3:00 PM
To: Dmitry Stogov
Cc: Derick Rethans; internals Mailing List; Andi Gutmans; Stas
Malyshev; phpxcache
Subject: Re: [PHP-DEV] Patch for opcode caches
Hello Dmitry,
please don't apply. The patch looks rather rough and untested (see
below).
It was tested at least with Zend products and xcache.
Also I really disagree to making the engine even
more complex
and adding
even more different behavior ways. That way we just introduce more
errors
as we cannot test the engine in all its modes.
It is not a good argument to hide this from APC, eAccelerator
and xcache.
We simply do not have
the
infrastructure for that. And that means we will add even
more bugs.
You will able to test it with make test and new versions of
APC/eAccelerator/XCache ... At least I tested it in this way
without problems
Further more I am missgin a description what you really
do here and
why we need to do that.
This is the description of the problem
http://www.mail-archive.com/internals@lists.php.net/msg32601.html
It is well known to all opcode cache weiters, but it is not
possible to solve it 100% correctly without ZE modification
Ok Opcode caches have issues but so far all
attempts to do
somethign about that have been blocked. Now this one
apparently has a
new
option. But as far as I can tell it simply allows to change the
compiler to an opcode friendly order. If that is all what it does
than we should simply
drop all the options and do it anyway without flags.
As I remember opcode cache was planned as a part of PHP-6,
probably there we will able to follow your suggestion, but
for now I don't see any reason to make PHP slowdown (without caches).
Thank you for patch review
1) CG(extended_info) was a boolean falg, CG(compiler_options)
is a bitset one bit of which represents old CG(extended_info)
2) Changes related to ZEND_ACC_IMPLEMENT_INTERFACES fix
unnecessary zend_verify_abstarct_class() calls. (For some
reason it might be called twice for the same class)
3) ZEND_COMPILE_OPTION_... is to long, but I can accept this
and of couse I'll add comments as you requested.
4) zend_vm_opcodes.h is autogenerated file, zend_vm_gen.php
chenged the indents :)
5) I'll recheck the -e option. Probably I missied something there.
Thanks. Dmitry.
unnoticed.
marcus
Friday, March 7, 2008, 12:36:58 PM, you wrote:
Index: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.308.2.12.2.35.2.9
diff -u -p -d -r1.308.2.12.2.35.2.9 zend.c
--- Zend/zend.c 5 Mar 2008 13:34:12 -
1.308.2.12.2.35.2.9
+++ Zend/zend.c 7 Mar 2008 11:34:14 -
@@ -463,7 +463,7 @@ static void zend_set_default_compile_tim
CG(asp_tags) = asp_tags_default;
CG(short_tags) = short_tags_default;
CG(allow_call_time_pass_reference) =
ct_pass_ref_default;
- CG(extended_info) = extended_info_default;
+ CG(compiler_options) = compiler_options_default;
}
/* }}} */
Why rename this variable? It still is an exetended
information in the
compiler globals. It's full name would be
compiler_globals_extended_info' versus
'compiler_globals_compiler_options'.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.46
diff -u -p -d -r1.647.2.27.2.41.2.46 zend_compile.c
--- Zend/zend_compile.c 3 Mar 2008 15:07:04 -
1.647.2.27.2.41.2.46
+++ Zend/zend_compile.c 7 Mar 2008 11:34:15 -
[...]
@@ -2588,7 +2577,7 @@ ZEND_API void zend_do_inheritance(zend_c
if (ce-ce_flags
ZEND_ACC_IMPLICIT_ABSTRACT_CLASS ce-
type == ZEND_INTERNAL_CLASS) {
ce-ce_flags |=
ZEND_ACC_EXPLICIT_ABSTRACT_CLASS;
- } else {
+ } else if (!(ce-ce_flags
ZEND_ACC_IMPLEMENT_INTERFACES))
+ {
zend_verify_abstract_class(ce TSRMLS_CC);
}
}
@@ -2700,7 +2689,7 @@ ZEND_API
[PHP-DEV] php_stream_cast to fd
When php_stream_cast is passed any of the _AS_FD-like options, what is the ret argument supposed to point to? This does not seem to be decided consistently; from a quick survey: ext/openssl/xp_ssl.c: php_openssl_sockop_cast() presumes that *ret has sizeof(void *) ext/soap/php_http.c: stream_alive() presumes that *ret has sizeof(long) ext/standard/streamfuncs.c: stream_array_from_fd_set() presumes that *ret has sizeof(php_socket_t) main/streams/xp_socket.c: php_sockop_cast() presumes that *ret has sizeof(int) On 64-bit platforms, of course, at least half of these cases will break, since sizeof(int) != sizeof(long). This issue is the cause of http://bugs.php.net/bug.php?id=32979, where a 64-bit value is being written to an pointer to a 32-bit value on the stack, and trashing whatever follows it. joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparison: ('*' == 0) ... True or false
On Tue, Mar 11, 2008 at 11:17 AM, Scott McNaught [Synergy 8]
[EMAIL PROTECTED] wrote:
Hey guys,
I don't know whether to post this as a bug or not. But I was tricked when
programming today.
It seems that the character * is non-strictly equivalent to 0. Is this
the correct behavior or am I missing something?
Test case:
?php
var_dump('*' == 0);
?
Shows boolean(true).
I was unable to find any documentation as to why this would be the case.
http://www.php.net/manual/en/language.operators.comparison.php
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new version of check_parameters.php
On 11.03.2008 08:00, Alexandr Savchuk wrote: 3. There are really many problem reports about not optional var is initialized Also in most part of these cases not optional var is inialized by null value. Why is this requrement ? And why ? I believe this notice should be disabled, as it's not an error or something bad. Removing an initialization that is not required doesn't fix any problem, even though it _can_ be done without any harm. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparison: ('*' == 0) ... True or false
On 3/11/08, Scott McNaught [Synergy 8] [EMAIL PROTECTED] wrote:
I don't know whether to post this as a bug or not. But I was tricked when
programming today.
It seems that the character * is non-strictly equivalent to 0. Is this
the correct behavior or am I missing something?
Test case:
?php
var_dump('*' == 0);
?
Shows boolean(true).
I was unable to find any documentation as to why this would be the case.
try
?php
echo intval(*);
?
that should explain the situation ;)
--
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] Comparison: ('*' == 0) ... True or false
If you compare an integer with a string, the string is converted to a
number. If you compare two numerical strings, they are compared as
integers. Well... I just feel stupid now :)
I am writing something which is extracting parts of a crontab. The variable
contained * was being compared to 0.
This would have clicked for me had it been anything else, but because it was
* my thoughts were that there was some new wild-card thing going on that I
hadn't heard about.
Cheers guys and sorry for my dumb post!
Scott
-Original Message-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2008 8:25 PM
To: Scott McNaught [Synergy 8]
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Comparison: ('*' == 0) ... True or false
On Tue, Mar 11, 2008 at 11:17 AM, Scott McNaught [Synergy 8]
[EMAIL PROTECTED] wrote:
Hey guys,
I don't know whether to post this as a bug or not. But I was tricked
when programming today.
It seems that the character * is non-strictly equivalent to 0. Is this
the correct behavior or am I missing something?
Test case:
?php
var_dump('*' == 0);
?
Shows boolean(true).
I was unable to find any documentation as to why this would be the case.
http://www.php.net/manual/en/language.operators.comparison.php
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Comparison: ('*' == 0) ... True or false
Hey guys,
I don’t know whether to post this as a bug or not. But I was tricked when
programming today.
It seems that the character * is non-strictly equivalent to 0. Is this the
correct behavior or am I missing something?
Test case:
?php
var_dump('*' == 0);
?
Shows boolean(true).
I was unable to find any documentation as to why this would be the case.
Regards,
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparison: ('*' == 0) ... True or false
On 11.03.2008 13:17, Scott McNaught [Synergy 8] wrote: Hey guys, I don’t know whether to post this as a bug or not. But I was tricked when programming today. It seems that the character * is non-strictly equivalent to 0. Is this the correct behavior or am I missing something? http://www.php.net/manual/en/language.operators.comparison.php Ask such questions in php-general@, please. Thank you. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: mimmi
distributing a new package -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
On Mon, Mar 10, 2008 at 6:41 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I must be misunderstanding the patch then - doesn't it change behavior of the engine so that parent:: doesn't mean parent of __CLASS__ anymore? If so, could you explain again what it does? Of course parent:: still means parent. The change in behavior from the current patch is just that once you call parent::someMethod you will still have access to overridden methods in child classes which with the current patch is not possible. Again, it just provides complete polymorphism for statics. parent:: is very simple thing - it means use the name of the parent class here. I do not thing changing it is a good idea. I am of the opinion that parent:: simply means call the parent function which doesn't change with the patch. I understand that you do not think it is a good, but I and many other people that have expressed their opinion on list regarding this matter disagree with you. You seem to be very focused on the parent:: issue without looking at the whole picture. Like I said before, I think all of the arguments have been hashed out. I would just like a yes or no decision that preferably reflects the desire of the user base. It would be fantastic if some more decision makers had some time to give their input. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request: nycynik
i want to make changes to a pear module to support iCalendars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new version of check_parameters.php
Hi,
Thanks for working on this. However I don't think more effort should be
wasted with this script. It's a bogus approach to the problem and it will
always generate many false-positives (disclaimer: I'm the author of the
original script and it was like a POC).
Thus my idea is to move along to use a real C/C++ front-end and perform the
things correctly. For example, the new LLVM's clang frontend is really easy
to work with. That's why I've proposed this for a gsoc project. It's fairly
easy for someone with little compiler knowledge, yet it gives enough work to
be a gsoc project.
Regards,
Nuno
- Original Message -
From: Alexandr Savchuk [EMAIL PROTECTED]
To: internals@lists.php.net
Sent: Tuesday, March 11, 2008 5:00 AM
Subject: [PHP-DEV] new version of check_parameters.php
Hello developers.
I saw some days ago that
there is need in rewriting of check_parameters.php to be less
false-positive and so on...
So i wrote new version - based on state machines _and_ regex.
Base checks are the same, only reporting is improved.
There is simple comparision:
-- on old version my php-5.2.5 source old util gives ~180 problems
(excluding optional, non optional params initialization,
reporting_level is setted up to 5):
# php ./scripts/dev/check_parameters.php //php5.2-200803061530 |
grep -iv 'optional var not initialized' | grep -iv 'not optional var
is initialized' ./old1.log
# wc -l ./old1.log
181 ./old1.log
new gives ~150 problems :)
# php /check_code.php -v 5 //php5.2-200803061530 |grep -iv
'OPTIONAL var IS NOT' | grep -iv 'NOT OPTIONAL var IS initialized'
/new1.log
# wc -l /new1.log
147 /new1.log
Some problems are unavoided:
- external variable definition (~60)
* 'php_com_variant_class_entry' - 11 reports
* 'date_ce_timezone' - 2 reports
* 'oci_lob_class_entry_ptr' - 26 reports
* 'text**' - 7 reports
* 'oci_coll_class_entry_ptr' - 10 reports
* 'zend_ce_traversable' - 3 reports
* others ...
- too complex cases of parsing ( can be fixed by hacks but it's wrong...)
(~5)
, others will be solved by more correct parsing
and some will be fixed in source code (i think :) ), for example:
ext/iconv/iconv.c [] iconv_mime_encode : field_value: expected
char** but got const char** [3]
ext/mysqli/mysqli_nonapi.c [] mysqli_connect : hostname_len: expected
int* but got unsigned int* [2]
ext/mysqli/mysqli_nonapi.c [] mysqli_connect : username_len: expected
int* but got unsigned int*[4]
ext/mysqli/mysqli_nonapi.c [] mysqli_connect : passwd_len: expected
int* but got unsigned int* [6]
ext/mysqli/mysqli_nonapi.c [] mysqli_connect : dbname_len: expected
int* but got unsigned int* [8]
ext/mysqli/mysqli_nonapi.c [] mysqli_connect : socket_len: expected
int* but got unsigned int* [11]
ext/openssl/openssl.c [] openssl_seal : the '/' specifier cannot be
applied to 'a'
ext/pgsql/pgsql.c [] pg_field_table : the '!' specifier cannot be applied
to 'b'
ext/pgsql/pgsql.c [] pg_copy_from : the '/' specifier cannot be applied to
's'
ext/pgsql/pgsql.c [] pg_meta_data : table_name_len: expected int*
but got uint* [3]
ext/pgsql/pgsql.c [] pg_convert : option: expected long* but got
ulong* [5]
ext/pgsql/pgsql.c [] pg_insert : option: expected long* but got ulong*
[5]
ext/pgsql/pgsql.c [] pg_update : option: expected long* but got ulong*
[6]
ext/pgsql/pgsql.c [] pg_delete : option: expected long* but got ulong*
[5]
ext/pgsql/pgsql.c [] pg_select : option: expected long* but got ulong*
[5]
ext/standard/streamsfuncs.c [] stream_socket_client : the '!'
specifier cannot be applied to 'd'
, so i believe final number will be ~70-80 ...
There are also need to do:
* write tests
* rewrite dropping comments from code
* return missed current_line function
* replace other regexes by statemachines where it is possible
* improve more maintainability
* write docu
* smth else ?
So it's not last version...
But please check it if you have time. You can see utility on [1]
(I don't creare patch because of it is the same as downloading new
version - too many changes)
Also i have questions:
1. in many problem reports there are unsigned int (or uint, or ulong
- long or smth else) to int assigning. Is it safe ? If yes, then i
need to process this in code
2. There are really many problem reports about optional var is not
initialized
Is there a requrement for reporting about it ? And why ?
3. There are really many problem reports about not optional var is
initialized
Also in most part of these cases not optional var is inialized by null
value. Why is this requrement ? And why ?
4. there is code like:
// separate_zval_if_not_ref
case '/':
//FIXME could not understand from why it so
if ( !in_array($prev_char, array('r', 'z')) ) {
self::error(the '/' specifier cannot be applied to
'$prev_char');
}
break;
Why ? In readme.parameter_parsing_api docu i can't find any related to
it information.
Links:
[1] http://sawoy.mylivepage.com/file/?fileid=2830
Re: [PHP-DEV] 5.3 Release Planning
Hi! Of course parent:: still means parent. The change in behavior from the current patch is just that once you call parent::someMethod you will still have access to overridden methods in child classes which with the current patch is not possible. Again, it just provides complete polymorphism for statics. OK, looks like I misunderstood what your patch does. Sorry for that. However, I'm still concerned that foo:: and parent:: would work differently. IMO, better solution would be to have all :: calls change called_class, but have also some way to call it without changing called_class. Something like your forward_static_call, but I'm not sure not using callbacks is a good idea - all caller function use callbacks now. Actually, what I'd do would be to generalize forward_static_call (which I think also needs better name :) and call_user_func into one function (internally) that has parameter which tells if to update or not update called_class. -- 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] 5.3 Release Planning
On Tue, Mar 11, 2008 at 4:31 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: IMO, better solution would be to have all :: calls change called_class, but have also some way to call it without changing called_class. Something like your forward_static_call, but I'm not sure not using callbacks is a good idea - all caller function use callbacks now. Actually, what I'd do would be to generalize forward_static_call (which I think also needs better name :) and call_user_func into one function (internally) that has parameter which tells if to update or not update called_class. I do agree about using a callback with forward_static_call, but one thing that worries me is that opens the door to really bizzare functionality where the called_class could wind up being outside of the inheritance chain of the method being called. If this could be overcame I think it would be relatively easy to consolidate this code internally. I will look at it this evening and tomorrow. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
