Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25367 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64756 invoked by uid 1010); 16 Aug 2006 10:14:34 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 64726 invoked from network); 16 Aug 2006 10:14:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Aug 2006 10:14:34 -0000 X-PHP-List-Original-Sender: php_lists@realplain.com X-Host-Fingerprint: 69.179.208.43 msa3-mx.centurytel.net Linux 2.4/2.6 Received: from [69.179.208.43] ([69.179.208.43:53267] helo=msa3-mx.centurytel.net) by pb1.pair.com (ecelerity 2.1.1.8 r(12549M)) with ESMTP id 19/1A-11355-BFFE2E44 for ; Wed, 16 Aug 2006 06:14:20 -0400 Received: from pc1 (207-119-220-231.dyn.centurytel.net [207.119.220.231]) by msa3-mx.centurytel.net (8.13.6/8.13.6) with SMTP id k7GAEFXx021309; Wed, 16 Aug 2006 05:14:15 -0500 Message-ID: <002c01c6c11c$bb024110$0201a8c0@pc1> To: , "Pierre" References: <005301c6bec7$783e5c80$0201a8c0@pc1> <006d01c6bedd$c86c7a00$0201a8c0@pc1> <35405.67.108.68.40.1155598740.squirrel@www.l-i-e.com> <004801c6c040$591276a0$0201a8c0@pc1> <001e01c6c115$e69bec10$0201a8c0@pc1> Date: Wed, 16 Aug 2006 05:14:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Subject: Re: [PHP-DEV] [PATCH] array_count_values bug: mishandling of numbers with leading whitespace From: php_lists@realplain.com ("Matt W") Hi Pierre, ----- Original Message ----- From: "Pierre" Sent: Wednesday, August 16, 2006 > Hello Matt, > > > > Which part of "We need to sit down and come up with a proposal?" did > > > you not understand? seriously? > > > > Nothing. :-) But the patch is all I know of, so that was my proposal. > > Maybe with the "sitting down," "if" to change this function would be the > > decision, but not "what" to change, as I only see 2 options: Do nothing; or > > fix the bug, which if there's a change, I'm pretty sure the behavior my > > patch provides will be the final result. I hope you guys DO see that > > there's a bug, and are simply wanting to be careful with changes. > > We are runing in circles, I do not have the times for that sorry. I I know, I'm sorry! :-) > answered many times the questions regarding your hope, explaining the > best way to take to solve this specific issue and all other related to > numeric strings. Andrei did too. have nothing else to say for now :) > > I will start the draft next week, let me know if you like to help. Sure, I could, but I'm not sure how much I'd help. :-/ If it's on the list, I can offer comments or such regarding anything I think (if this is mostly is_numeric* stuff you will draft) -- I thought I'd have a quick commented example of what *I* thought of for is_numeric* by now, but didn't get to it yet. I wanted to reply to your message from last week in the is_numeric* thread... One last thing about the array function I've not mentioned... ('Course I realized after the last mail -- I tried this the other day, but it was my patched code (oops), so it didn't mess up.) On 32-bit, using string value of 2^32-1: $a['2147483647']=1; $b=array_count_values(array('2147483647')); var_dump($a, $b); array(1) { ["2147483647"]=> int(1) } array(1) { [2147483647]=> int(1) } Again, it's behaving differently by converting that value to number. (Note: To be fair, I'd say in this case, it's a tiny bug in regular array key handling ("symtable" functions), but I'll keep that for later -- super simple to fix, I think. And safe. :-)) > --Pierre Don't need to waste time replying to this. ;-) Thanks for your time, Matt