Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25366 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38995 invoked by uid 1010); 16 Aug 2006 09:25:28 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 38980 invoked from network); 16 Aug 2006 09:25:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Aug 2006 09:25:28 -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:54761] helo=msa3-mx.centurytel.net) by pb1.pair.com (ecelerity 2.1.1.8 r(12549M)) with ESMTP id E0/18-11355-684E2E44 for ; Wed, 16 Aug 2006 05:25:28 -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 k7G9PMbx029919; Wed, 16 Aug 2006 04:25:22 -0500 Message-ID: <001e01c6c115$e69bec10$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> Date: Wed, 16 Aug 2006 04:25:22 -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: Tuesday, August 15, 2006 > Hello, > > On 8/15/06, Matt W wrote: > > Hi Pierre, > > > > I will go ahead and enter a Bug report for this in a bit ('cause there's > > definitely a bug), just so it's in the official place (preferred, I guess?) > > and doesn't keep going here on the list. :-) > > Please don't. I have no more ways or words to explain you what needs > to be done.... Please ask me if you still don't get it. I was actually thinking the same thing. ;-) Don't what, don't enter a Bug report? Sorry, I already had awhile before getting your reply (but you've probably seen it). I didn't know it was bad to record the bug there -- so anyone affected could find it easier, or it's noted in the PHP changelog, assuming it's eventually fixed. > > ----- Original Message ----- > > From: "Pierre" > > Sent: Monday, August 14, 2006 > > > > > Hello, > > > ... > > > I did not say it should be broken. All I said (and confirmed by > > > Andrei) is that we should first sit down and figure out what, how and > > > when we can/should change something. It seems to me as the sanest > > > attitude given the insane amount of senseless changes. > > > > > > There is no need to push a patch just to bring another entry to this > > > changelog. As I already suggested, we can work together on a proposal > > > and bring it to a conclusion. > > > Just to be sure, you are just talking about the array_count_values() > > function and not the is_numeric... stuff? > > No, I'm talking about __all__ cases :-). This function or the array > keys in general is only one issue, there is some more. But I've only been talking about this one specific array_count_values bug in this thread... As I've said, I haven't seen "some more" places where this specific behavior exists. > 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. BTW, I think my Bug report (#38464) shows the problem well (I mean, better than my previous mails). I use this function to count words from text, and other than it being slower than it could with my patch, the leading spaces + numbers issue wouldn't really affect me (since I split on spaces), BUT after also realizing that a leading sign is also an issue, then it obviously could affect my code (if signs are allowed as part of a "word"), which is a problem, as the "word" characters have been modified. :-( Hmm, I haven't tried it, but I wonder if a userland foreach loop would be faster than using the function (and it would work correctly), unlike in PHP 4. > --Pierre Matt