[PHP-DEV] How to contribute for PHP Internals
Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) about me : I'm french, i have 24 years, I live in Paris, i have some experiences in C, PHP and GNU Tools. if you want to know more about me, you can see my blog: http://sahid.funraill.org or my little projects : http://code.google.com/p/ootemplate/ http://code.google.com/p/postmemd/ lots of thanks, Sahid Ferdjaoui -- ~/sahid http://sahid.funraill.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 snapshot sha1() differences.
Hi. Just checking out the latest NTS VC9 Win32 snapshots and the sha1()'s are different. php-5.3-nts-VC9-x86 : 2009-May-14 11:00:00 Failed Is b406e5605d5c222b0d12051cfdac6ad1b7b0ea5c php-5.3-nts-VC9-x86 : 2009-May-14 11:00:00 Failed Is 195e1358973fe96118dcb569921eff4ad121d82c The other 5.3 and all 5.2 sha1()'s are fine. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #48256 readline crash
Tim Starling kirjoitti: The readline extension links both libreadline and libhistory. This is unnecessary, and inspection of the readline example programs since version 2.0 implies that it has always been unnecessary. Both libraries include history.o, so linking to both gives you two copies of that module. I'd be quite worried about this what you mentioned in that report: The libraries are loaded in the problematic order in Ubuntu 9.04, previous versions of Ubuntu appeared to work. WHY does newer Ubuntu load some lib before the other? I'd find that out to prevent other similar problems. The bug occurs when, due to operating system vagaries, libhistory loads before libreadline. This causes PHP's readline_add_history() to add history entries to libhistory's copy of the_history. Then when readline() is called, libreadline attempts to read the other copy of the_history. The result is a null pointer dereference in libreadline's previous_history() function. The solution is to remove all references to libhistory in ext/readline/config.m4. I have patched this in and tested it. Apparently there are other OSes with some problems as well with it. I removed the stuff in CVS now. This bug was closed as bogus on bugs.php.net due to some temporary short-circuit in the mind of a bug tracker admin. It's totally PHP's fault and there's nothing any distro can do to fix it. Heh..I have short temper but definately no short-circuits. Rather long cabling maybe. :D --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fix for bug #45540 not in PHP_5_2
Hi, Why wasn't this fix merged to PHP_5_2? It's clearly a bug and it really should be fixed in the stable branch as well.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
2009/5/14 Sahid Ferdjaoui sahid.ferdja...@gmail.com: Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) The best way to get started is to check http://php.net/anoncvs make a checkout of HEAD (php6) and then go to http://bugs.php.net start making patches and attach them to bug reports. From there you will gain developers trust (People will be tired of committing all your patches) and at some point you'll be granted with an account :) Good luck and welcome :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fix for bug #45540 not in PHP_5_2
Hi, On Thu, 2009-05-14 at 17:14 +0300, Jani Taskinen wrote: Hi, Why wasn't this fix merged to PHP_5_2? It's clearly a bug and it really should be fixed in the stable branch as well.. The fix changes a parameter of php_stream_url_wrap_http_ex(), I guess that I thought that it was unsuitable for 5.2. Or maybe at this time I thought the 5.2 branch was closed. The parameter change may not break code using it, I will merge this. Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.10
We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Thanks, Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Since 5.3 DOES require some work to port legacy applications over PLEASE do not discontinue 5.2 security fixes until 5.3 has bedded down ( remember 5.1 ... ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
On Thu, May 14, 2009 at 18:45, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Since 5.3 DOES require some work to port legacy applications over Do you have a quick list of things that is required so we can document them, or maybe even fix? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Request decoding in PHP 6 [patch]
Request decoding is one of a few remaining pieces of the Unicode puzzle. The proposed solution was outlined in a blog post [1] I wrote a while back. There has been no movement on this front pretty much since then, but now that 5.3 is wrapping up I want to put some momentum behind PHP 6. Towards that, I have been working on a patch that implements the request decoding functionality. The patch [2] and the notes [3] are linked to below. This is not a final effort by any means, but I believe the patch is solid and the rest can be done in a similar manner. Right now, it implements only $_POST, $_GET, $_FILES, and $_REQUEST decoding. Deciding how to handle $_COOKIES is the next step, which is mentioned in the notes. Please take a look and comment. -Andrei [1] http://gravitonic.com/2007/02/php-6-and-request-decoding [2] http://gravitonic.com/dump/request_decoding.patch [3] http://gravitonic.com/dump/request_decoding.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Hi, On Thu, May 14, 2009 at 6:21 PM, Ilia Alshanetsky i...@prohost.org wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Thanks for the notice! End of the month for the RC1 is perfect. About discontinuing 5.2, it may be too early to decide. Cheers, -- 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] PHP 5.2.10
On Thu, May 14, 2009 at 10:05 AM, Pierre Joye pierre@gmail.com wrote: Hi, On Thu, May 14, 2009 at 6:21 PM, Ilia Alshanetsky i...@prohost.org wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Thanks for the notice! End of the month for the RC1 is perfect. About discontinuing 5.2, it may be too early to decide. This makes me a little sad - I was thinking PHP 5.3 was closer to production. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why does $_REQUEST exist?
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request decoding in PHP 6 [patch]
Andrei, For you point #7 regarding the session extension. Perhaps we should make a simple API allowing extensions to register callbacks to execute on input data. Once request encoding is set, the callbacks can be ran for GPC input allow extensions (not just session) to do their input processing in a safe manner. We can even take it a step further and make it secondary to ext/filter processing, for some security bits. Ilia Alshanetsky On 14-May-09, at 12:57 PM, Andrei Zmievski wrote: Request decoding is one of a few remaining pieces of the Unicode puzzle. The proposed solution was outlined in a blog post [1] I wrote a while back. There has been no movement on this front pretty much since then, but now that 5.3 is wrapping up I want to put some momentum behind PHP 6. Towards that, I have been working on a patch that implements the request decoding functionality. The patch [2] and the notes [3] are linked to below. This is not a final effort by any means, but I believe the patch is solid and the rest can be done in a similar manner. Right now, it implements only $_POST, $_GET, $_FILES, and $_REQUEST decoding. Deciding how to handle $_COOKIES is the next step, which is mentioned in the notes. Please take a look and comment. -Andrei [1] http://gravitonic.com/2007/02/php-6-and-request-decoding [2] http://gravitonic.com/dump/request_decoding.patch [3] http://gravitonic.com/dump/request_decoding.txt -- 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
Re: [PHP-DEV] PHP 5.2.10
IMHO, 5.2 should be stopped as soon as 5.3.0 is released. On Thu, May 14, 2009 at 2:09 PM, Michael Shadle mike...@gmail.com wrote: On Thu, May 14, 2009 at 10:05 AM, Pierre Joye pierre@gmail.com wrote: Hi, On Thu, May 14, 2009 at 6:21 PM, Ilia Alshanetsky i...@prohost.org wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Thanks for the notice! End of the month for the RC1 is perfect. About discontinuing 5.2, it may be too early to decide. This makes me a little sad - I was thinking PHP 5.3 was closer to production. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. I would really like to make a patch to ext/json to expose the encoding/decoding functions so that they can be called from other extensions. I should be able to wrap this up in the next few days. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request decoding in PHP 6 [patch]
Ilia Alshanetsky wrote: Andrei, For you point #7 regarding the session extension. Perhaps we should make a simple API allowing extensions to register callbacks to execute on input data. Once request encoding is set, the callbacks can be ran for GPC input allow extensions (not just session) to do their input processing in a safe manner. We can even take it a step further and make it secondary to ext/filter processing, for some security bits. This is a good idea. However, we still have the issue of extensions needing some data from the request before $_POST or $_GET are ever mentioned in the script, since the decoding is done only at that time. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
Hello David, I will follow your advice now :) Thanks ! -- ~/sahid http://sahid.funraill.org On Thu, May 14, 2009 at 6:16 PM, David Coallier dav...@php.net wrote: 2009/5/14 Sahid Ferdjaoui sahid.ferdja...@gmail.com: Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) The best way to get started is to check http://php.net/anoncvs make a checkout of HEAD (php6) and then go to http://bugs.php.net start making patches and attach them to bug reports. From there you will gain developers trust (People will be tired of committing all your patches) and at some point you'll be granted with an account :) Good luck and welcome :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
David Coallier wrote: 2009/5/14 Sahid Ferdjaoui sahid.ferdja...@gmail.com: Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) The best way to get started is to check http://php.net/anoncvs make a checkout of HEAD (php6) and then go to http://bugs.php.net start making patches and attach them to bug reports. From there you will gain developers trust (People will be tired of committing all your patches) and at some point you'll be granted with an account :) Good luck and welcome :) Yes, welcome! Perhaps you could create a get involved wiki section based on what you find out about getting involved? Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
This is a new feature, so it would be more appropriate for 5.3/6 more so then for 5.2 IMHO. Ilia Alshanetsky On 14-May-09, at 1:39 PM, Andrei Zmievski wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. I would really like to make a patch to ext/json to expose the encoding/decoding functions so that they can be called from other extensions. I should be able to wrap this up in the next few days. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Is there any chance of revisiting this issue? I mean, to change the
default back to SORT_STRING. We now have a couple more reports
regarding this:
http://bugs.php.net/47370#c147594
http://bugs.php.net/48115
Regards,
Moriyoshi
On Fri, Feb 27, 2009 at 8:30 AM, Ilia Alshanetsky i...@prohost.org wrote:
Moriyoshi,
First of thank you for taking the time to provide examples regarding the
issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to this change.
While your example does show a change, I am not convinced (sorry) that it is
an adverse one, type-different comparison is always tricky and not entirely
reliable and I think demonstrates more of a corner-case situation.
I think our best option at this time is to release 5.2.9 as quickly as
possible as it introduces a number of crucial fixes and if your comments are
validated via user feedback we can adjust the values with 5.2.10 that can be
repackaged fairly rapidly. IMHO the current functionality is desired and is
acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to the
third.
Moriyoshi
--
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
Re: [PHP-DEV] PHP 5.2.10
It doesn't impact anything though, does it? And it would really help for implementing json-based serializers (such as for memcached). -Andrei Ilia Alshanetsky wrote: This is a new feature, so it would be more appropriate for 5.3/6 more so then for 5.2 IMHO. Ilia Alshanetsky On 14-May-09, at 1:39 PM, Andrei Zmievski wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. I would really like to make a patch to ext/json to expose the encoding/decoding functions so that they can be called from other extensions. I should be able to wrap this up in the next few days. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Andrei,
I would also like to get this reverted (in _all_ branches!) as it really is huge
WTF and another BC breakage, totally unnecessary as such.
--Jani
Moriyoshi Koizumi kirjoitti:
Is there any chance of revisiting this issue? I mean, to change the
default back to SORT_STRING. We now have a couple more reports
regarding this:
http://bugs.php.net/47370#c147594
http://bugs.php.net/48115
Regards,
Moriyoshi
On Fri, Feb 27, 2009 at 8:30 AM, Ilia Alshanetsky i...@prohost.org wrote:
Moriyoshi,
First of thank you for taking the time to provide examples regarding the
issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to this change.
While your example does show a change, I am not convinced (sorry) that it is
an adverse one, type-different comparison is always tricky and not entirely
reliable and I think demonstrates more of a corner-case situation.
I think our best option at this time is to release 5.2.9 as quickly as
possible as it introduces a number of crucial fixes and if your comments are
validated via user feedback we can adjust the values with 5.2.10 that can be
repackaged fairly rapidly. IMHO the current functionality is desired and is
acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to the
third.
Moriyoshi
--
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
Re: [PHP-DEV] PHP 5.2.10
It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) --Jani Andrei Zmievski kirjoitti: It doesn't impact anything though, does it? And it would really help for implementing json-based serializers (such as for memcached). -Andrei Ilia Alshanetsky wrote: This is a new feature, so it would be more appropriate for 5.3/6 more so then for 5.2 IMHO. Ilia Alshanetsky On 14-May-09, at 1:39 PM, Andrei Zmievski wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. I would really like to make a patch to ext/json to expose the encoding/decoding functions so that they can be called from other extensions. I should be able to wrap this up in the next few days. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Ilia Alshanetsky kirjoitti: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Can we add some sort of notice to that release, something like this: If you did not test a release candidate, any bug report send about issue introduced in this release will automatically be bogus. ?? :D --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Maybe only allow people who ran make test and submitted the results during the RC phase to submit bugs, eh? ;-) Ilia Alshanetsky On 14-May-09, at 2:49 PM, Jani Taskinen wrote: Ilia Alshanetsky kirjoitti: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Can we add some sort of notice to that release, something like this: If you did not test a release candidate, any bug report send about issue introduced in this release will automatically be bogus. ?? :D --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Andrei,
I think Moriyoshi has a point here there are several reports by people
who are affected by this, I think it makes sense to leave the
introduced functionality as is in 5.3/6, but for PHP 5.2 it probably
should be rolled back.
Ilia Alshanetsky
On 14-May-09, at 2:21 PM, Moriyoshi Koizumi wrote:
Is there any chance of revisiting this issue? I mean, to change the
default back to SORT_STRING. We now have a couple more reports
regarding this:
http://bugs.php.net/47370#c147594
http://bugs.php.net/48115
Regards,
Moriyoshi
On Fri, Feb 27, 2009 at 8:30 AM, Ilia Alshanetsky i...@prohost.org
wrote:
Moriyoshi,
First of thank you for taking the time to provide examples
regarding the
issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to
this change.
While your example does show a change, I am not convinced (sorry)
that it is
an adverse one, type-different comparison is always tricky and not
entirely
reliable and I think demonstrates more of a corner-case situation.
I think our best option at this time is to release 5.2.9 as quickly
as
possible as it introduces a number of crucial fixes and if your
comments are
validated via user feedback we can adjust the values with 5.2.10
that can be
repackaged fairly rapidly. IMHO the current functionality is
desired and is
acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp
wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other
than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not
acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to
the
third.
Moriyoshi
--
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
Re: [PHP-DEV] PHP 5.2.10
Andrei, There is no question about functionality being useful for some people. But what is the point of different branches if we put whatever we want into each branch? We may as well stick to one branch and commit features, bug fixes, etc... into it. Ilia Alshanetsky On 14-May-09, at 2:54 PM, Andrei Zmievski wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/iconv iconv.c
Ilia, do you still see any problem merging this to 5.2?
Moriyoshi
On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Ilia?
I guess the chances of getting this merged Moriyoshi will increase by
100% if you have a testcase..
-Hannes
On Tue, Mar 17, 2009 at 07:31, Moriyoshi Koizumi moriyo...@php.net wrote:
moriyoshi Tue Mar 17 05:31:04 2009 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/iconv iconv.c
Log:
- MFH: Make iconv filter accept '.' as the delimiter between encoding names
as
well as '/'. It's impossible to specify the filter in php://filter without
this fix.
# I hope this to be merged to 5.2 as well. This doesn't break BC as there is
# no such encoding name that contains '.'. (Andif there were to be such one,
# the filter is failed in the first place since it also uses '.' for the
# delimiter between the filter name and the from encoding name.
http://cvs.php.net/viewvc.cgi/php-src/ext/iconv/iconv.c?r1=1.124.2.8.2.20.2.13r2=1.124.2.8.2.20.2.14diff_format=u
Index: php-src/ext/iconv/iconv.c
diff -u php-src/ext/iconv/iconv.c:1.124.2.8.2.20.2.13
php-src/ext/iconv/iconv.c:1.124.2.8.2.20.2.14
--- php-src/ext/iconv/iconv.c:1.124.2.8.2.20.2.13 Wed Dec 31 11:15:37
2008
+++ php-src/ext/iconv/iconv.c Tue Mar 17 05:31:04 2009
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: iconv.c,v 1.124.2.8.2.20.2.13 2008/12/31 11:15:37 sebastian Exp $ */
+/* $Id: iconv.c,v 1.124.2.8.2.20.2.14 2009/03/17 05:31:04 moriyoshi Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -2759,7 +2759,7 @@
return NULL;
}
++from_charset;
- if ((to_charset = strchr(from_charset, '/')) == NULL) {
+ if ((to_charset = strpbrk(from_charset, /.)) == NULL) {
return NULL;
}
from_charset_len = to_charset - from_charset;
--
PHP CVS Mailing List (http://www.php.net/)
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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/iconv iconv.c
Should be fine
Ilia Alshanetsky
On 14-May-09, at 3:14 PM, Moriyoshi Koizumi wrote:
Ilia, do you still see any problem merging this to 5.2?
Moriyoshi
On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Ilia?
I guess the chances of getting this merged Moriyoshi will increase by
100% if you have a testcase..
-Hannes
On Tue, Mar 17, 2009 at 07:31, Moriyoshi Koizumi
moriyo...@php.net wrote:
moriyoshi Tue Mar 17 05:31:04 2009 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/iconv iconv.c
Log:
- MFH: Make iconv filter accept '.' as the delimiter between
encoding names as
well as '/'. It's impossible to specify the filter in php://
filter without
this fix.
# I hope this to be merged to 5.2 as well. This doesn't break BC
as there is
# no such encoding name that contains '.'. (Andif there were to
be such one,
# the filter is failed in the first place since it also uses '.'
for the
# delimiter between the filter name and the from encoding name.
http://cvs.php.net/viewvc.cgi/php-src/ext/iconv/iconv.c?r1=1.124.2.8.2.20.2.13r2=1.124.2.8.2.20.2.14diff_format=u
Index: php-src/ext/iconv/iconv.c
diff -u php-src/ext/iconv/iconv.c:1.124.2.8.2.20.2.13 php-src/ext/
iconv/iconv.c:1.124.2.8.2.20.2.14
--- php-src/ext/iconv/iconv.c:1.124.2.8.2.20.2.13 Wed Dec 31
11:15:37 2008
+++ php-src/ext/iconv/iconv.c Tue Mar 17 05:31:04 2009
@@ -18,7 +18,7 @@
+
--+
*/
-/* $Id: iconv.c,v 1.124.2.8.2.20.2.13 2008/12/31 11:15:37
sebastian Exp $ */
+/* $Id: iconv.c,v 1.124.2.8.2.20.2.14 2009/03/17 05:31:04
moriyoshi Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -2759,7 +2759,7 @@
return NULL;
}
++from_charset;
- if ((to_charset = strchr(from_charset, '/')) == NULL) {
+ if ((to_charset = strpbrk(from_charset, /.)) == NULL) {
return NULL;
}
from_charset_len = to_charset - from_charset;
--
PHP CVS Mailing List (http://www.php.net/)
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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Hannes Magnusson wrote: On Thu, May 14, 2009 at 18:45, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. Since 5.3 DOES require some work to port legacy applications over Do you have a quick list of things that is required so we can document them, or maybe even fix? Several hundred warnings that are not present currently? The code base has not YET dropped PHP4 compatibility, so a PHP5 only build may be required to 'tidy things up' and we are not able as yet to do THAT :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request decoding in PHP 6 [patch]
Andrei Zmievski kirjoitti: Ilia Alshanetsky wrote: Andrei, For you point #7 regarding the session extension. Perhaps we should make a simple API allowing extensions to register callbacks to execute on input data. Once request encoding is set, the callbacks can be ran for GPC input allow extensions (not just session) to do their input processing in a safe manner. We can even take it a step further and make it secondary to ext/filter processing, for some security bits. This is a good idea. However, we still have the issue of extensions needing some data from the request before $_POST or $_GET are ever mentioned in the script, since the decoding is done only at that time. You just need to call zend_is_auto_global() to trigger the init. btw. ext/session does only need the stuff in RINIT if session.auto_start is enabled. Just remove that option. :D --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
hi Ilia, On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. It is actually not about adding features. If I understand correctly what Andrei likes to have, it is only about exposing the JSON API. That means no code change (no new feature or whatever else) but only adding the right PHP_API related declaration to the right place and install the json header. That could actually be very useful with no impact on the code (userland or extensions). I think we should allow this change. Cheers, -- 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] PHP 5.2.10
Ilia Alshanetsky wrote: Andrei, There is no question about functionality being useful for some people. But what is the point of different branches if we put whatever we want into each branch? We may as well stick to one branch and commit features, bug fixes, etc... into it. I would fully agree with you if this concerned a user-visible API change or a new feature. But this is simply exposing a couple of internal functions so that they are visible from other extensions, and, arguably, something that should have been done properly from the beginning. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
If we are simply changing the declaration that should be fine, is there a patch available for review? Ilia Alshanetsky On 14-May-09, at 4:04 PM, Pierre Joye wrote: hi Ilia, On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. It is actually not about adding features. If I understand correctly what Andrei likes to have, it is only about exposing the JSON API. That means no code change (no new feature or whatever else) but only adding the right PHP_API related declaration to the right place and install the json header. That could actually be very useful with no impact on the code (userland or extensions). I think we should allow this change. Cheers, -- 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] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Ilia Alshanetsky wrote: Andrei, I think Moriyoshi has a point here there are several reports by people who are affected by this, I think it makes sense to leave the introduced functionality as is in 5.3/6, but for PHP 5.2 it probably should be rolled back. Fine. Our sorting/comparison is pretty screwed up anyway, if 400.00 is the same as 400. Maybe it makes sense for array_unique() to accept an optional flag at the end to specify the type of sorting. And we should add one that uses is_identical_function() to prevent crap like that. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Not yet. It's a simple declaration change for json_encode_r(), but json_decode() doesn't have json_decode_r(), so we'd need to create it from the guts of json_decode(). -Andrei Ilia Alshanetsky wrote: If we are simply changing the declaration that should be fine, is there a patch available for review? Ilia Alshanetsky On 14-May-09, at 4:04 PM, Pierre Joye wrote: hi Ilia, On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. It is actually not about adding features. If I understand correctly what Andrei likes to have, it is only about exposing the JSON API. That means no code change (no new feature or whatever else) but only adding the right PHP_API related declaration to the right place and install the json header. That could actually be very useful with no impact on the code (userland or extensions). I think we should allow this change. Cheers, -- 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] Request decoding in PHP 6 [patch]
Jani Taskinen wrote: This is a good idea. However, we still have the issue of extensions needing some data from the request before $_POST or $_GET are ever mentioned in the script, since the decoding is done only at that time. You just need to call zend_is_auto_global() to trigger the init. I know that this is an option, but I don't think it's a good one, because it defeats the purpose of JIT. What's the point if we always process $_POST/$_GET/$_COOKIES without giving the user a chance to figure out what the encoding is? btw. ext/session does only need the stuff in RINIT if session.auto_start is enabled. Just remove that option. :D Heh. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Hi! We have a fair number of fixes in the 5.2 branch already and while 5.3 is making very good progress I think it is still ways off in terms of final release and stabilization. I think it makes sense to do one more 5.2 release before 5.3 is out and 5.2 can be discontinued. I would like to roll an RC1 by May 28th, so please get your fixes in. I think 5.2 should still be alive for security/critical fixes at least until we are sure 5.3 is tested enough in the field. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why does $_REQUEST exist?
Michael Shadle wrote:
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
bc? all the reasoning in the world won't justify it to 1 million
businesses running php 4 code which is reliant on $_REQUEST behind the
scenes.
although it would generate a tonne of freelance work :p
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] mysqli #35203 / #48065 Eliminate special case for calling procedures in mysqli
Ping? There's a fully formed patch here, with tests, to fix a mysqli bug. I haven't gotten any feedback. Here's the original message with the patch. http://news.php.net/php.internals/43773 Michael G Schwern wrote: This is a patch against 5.2.9 to fix mysqli::query so a user can call stored procedures the same as they do any other statement. No more multi_query() and next_result() work arounds necessary to avoid a Commands out of sync error. I note this has been rejected several times in the tracker as not being a bug. I feel its a clear encapsulation violation making the user special case a query just because it's calling a stored procedure. Aside from just being very inconvenient, some API wrappers around mysqli, Drupal 6 for example, leave the user with no way to get at mysqli::multi_query(). Anyhow, here's a complete patch with a test. The technique and code is lifted from Perl's DBD::mysql driver, which you can see here as mysql_st_free_result_sets() http://cpansearch.perl.org/src/CAPTTOFU/DBD-mysql-4.011/dbdimp.c Before each query it frees any results still hanging around on the connection, which is essentially what a user has to do. I'm not really a C programmer so I left most of the code as is, do/while loop and all. I'm not sure how mysqli normally handles errors so I just went with a printf() and return trusting that you'll fix that up. It causes test 057 to fail because that test deliberately generates an out of sync error, which my code diligently prints. So that should go away with fixed error handling. Thanks, Schwern -- ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
While I am stil wondering why we could not stop this kind of mess before the release, we should also revert the default for 5.3. There's no point making the behavior different between releases. Moriyoshi On Fri, May 15, 2009 at 5:10 AM, Andrei Zmievski and...@gravitonic.com wrote: Ilia Alshanetsky wrote: Andrei, I think Moriyoshi has a point here there are several reports by people who are affected by this, I think it makes sense to leave the introduced functionality as is in 5.3/6, but for PHP 5.2 it probably should be rolled back. Fine. Our sorting/comparison is pretty screwed up anyway, if 400.00 is the same as 400. Maybe it makes sense for array_unique() to accept an optional flag at the end to specify the type of sorting. And we should add one that uses is_identical_function() to prevent crap like that. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why does $_REQUEST exist?
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrix...@gmail.com wrote: bc? all the reasoning in the world won't justify it to 1 million businesses running php 4 code which is reliant on $_REQUEST behind the scenes. although it would generate a tonne of freelance work :p that code has to change for 5.3 or 6.0 anyway. now is the time to yank out some of the legacy crap. we don't want PHP to be like windows, do we? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault while looping through hash table
Hi all,
I'm having some issues with some custom embedding of the PHP sapi. I'm
trying to call PHP from Ruby and I'd like to be able to pass data back
and forth freely, but I'm running into segfaults. It works well enough
for small values, but for some large values, it crashes on me.
Currently my most immediate issue is when I'm passing a large string
to call_user_function, which itself is calling token_get_all. The file
I'm parsing is pretty big, so the hash table returned is also pretty
big (~500 records). But each time I loop through it, it segfaults half
way through, even if I don't touch the records at all. I ran gdb on it
and it tells me one of the internal hash pointers is invalid, which
I'm not sure how this could have happened, since I'm only iterating
through it. I've included a version of the function doing this below
[2], and a sample of the gdb session I used as well [3]. If you'd like
to see the original, plus the context of this operation, you can check
it out here [1].
I have a hunch the problem lies in the way I'm allocating (or not
allocating) the PHP variables involved. I did follow some of the
guidelines in the book Extending and Embedding PHP, but found that
my code worked without all of the conventions, so instead I just
omitted it when it didn't seem necessary.. And now I'm here :) If it
is down to my bad memory handling habits, it would really be helpful
if someone could point out, on what particular line, I'm doing things
wrong. Then I could probably figure it out from there.
Thanks,
- Farley
[1]
http://github.com/farleyknight/ionize/blob/f1ee49f2c0f8a331bd77d59243bf8392615c7eca/etc/php_eval_string/php_eval_string.c
[2] Code sample:
VALUE zval2rb_hsh_(zval zhash) {
VALUE rbhash = rb_hash_new();
char *string_key;
ulong num_key;
zval key, **value;
VALUE rbkey, rbvalue;
zend_hash_internal_pointer_reset(Z_ARRVAL(zhash));
printf(This hash table has %d entries\n,
zend_hash_num_elements(Z_ARRVAL(zhash)));
int current = 0;
while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)value)
== SUCCESS) {
current++;
printf(Currently on entry %d\n, current);
if (zend_hash_move_forward(Z_ARRVAL(zhash)) == SUCCESS)
printf(Done moving hash forward. Result was successful\n);
else
printf(Done moving hash forward. Result was a failure\n);
}
return rbhash;
}
[3] gdb session:
gdb ruby
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb) run test.rb
Starting program: /usr/local/bin/ruby test.rb
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) continue
Continuing.
calling phpversion
5.2.9
calling token get all, medium input
This hash table has 429 entries
Currently on entry 1
Done moving hash forward. Result was successful
Currently on entry 2
Done moving hash forward. Result was successful
Currently on entry 291
Done moving hash forward. Result was successful
[New Thread 0xb7d846b0 (LWP 13069)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d846b0 (LWP 13069)]
zend_hash_get_current_data_ex (ht=0x817fc48, pData=0xbfa3acb8,
pos=0x0) at /home/robinhoode/Desktop/php-5.2.9/Zend/zend_hash.c:1163
1163 *pData = p-pData;
(gdb) quit
The program is running. Exit anyway? (y or n) y
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault while looping through hash table
On Fri, May 15, 2009 at 12:31 PM, Farley Knight farleykni...@gmail.com wrote:
zend_hash_internal_pointer_reset(Z_ARRVAL(zhash));
printf(This hash table has %d entries\n,
zend_hash_num_elements(Z_ARRVAL(zhash)));
int current = 0;
while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)value)
== SUCCESS) {
current++;
printf(Currently on entry %d\n, current);
if (zend_hash_move_forward(Z_ARRVAL(zhash)) == SUCCESS)
printf(Done moving hash forward. Result was successful\n);
else
printf(Done moving hash forward. Result was a failure\n);
}
Does the problem persist if replacing the hashtable functions by the
_ex counterparts: zend_internal_pointer_reset_ex(),
zend_hash_get_current_data_ex() and zend_move_forward_ex()? These are
always recommended (I believe) because the internal HashPosition value
associated to a hashtable is also used in the user script.
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
