RE: Re: [PHP-DEV] [DRAFT] RFC - array_column() function

2012-06-26 Thread Ford, Mike
-Original Message- From: Morgan L. Owens [mailto:pack...@nznet.gen.nz] Sent: 25 June 2012 15:41 On 2012-06-25 04:19, Ralph Schindler wrote: The term 'column' makes a lot of sense for PDO working with database columns, but there is no concept of a 'column' in the array structure

[PHP-DEV] Re: Non ASCII char in php.ini [patch]

2012-06-26 Thread Christian Stocker
Hi Yeah, that looks very wrong. Do you want to commit it or should I? chregu On 25.06.12 10:48, Lior Kaplan wrote: Hi, We've noticed that the php.ini-development and php.ini-production include a UTF-8 character which looks weird under ASCII (or other simple locales). It was added with

[PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API

2012-06-26 Thread Anthony Ferrara
Hello All, I've taken the conversation of the previous simplified password hashing API, and generated a patch and draft RFC for it. The patch isn't ready yet (needs review, cleanup and testing), but it's a start. https://wiki.php.net/rfc/password_hash Please have a look and comment away!

Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings

2012-06-26 Thread Nikita Popov
On Sun, Jun 24, 2012 at 5:39 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: So how about: mixed json_last_error ( [bool $error_string = false] ) Returns the last error (if any) occurred during the last JSON encoding/decoding. By default an integer constant from the table below is returned. If

Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings

2012-06-26 Thread Stas Malyshev
Hi! Makes sense to me. So should I do this? Remove warnings + add string parameter for json_last_error? Looks fine. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] bug 54547

2012-06-26 Thread Christopher Jones
On 06/22/2012 12:08 AM, OISHI Kazuo wrote: Hi, In addition to == operator, , , =, and = operators are influenced. And, hexdecimal format for big number is now case-sensitive. http://www.mail-archive.com/internals@lists.php.net/msg58789.html Can you add some phpt tests for all the cases

Re: [PHP-DEV] bug 54547

2012-06-26 Thread OISHI Kazuo
Does this need an architecture specific SKIPIF? See the mention of PHP_INT_SIZE on http://qa.php.net/write-test.php Like this? === --SKIPIF-- ?php if (PHP_INT_SIZE != 8) die(skip this test is for 64bit platforms only); ?