Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54606 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78156 invoked from network); 15 Aug 2011 04:28:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2011 04:28:56 -0000 Authentication-Results: pb1.pair.com header.from=sebastian.krebs.berlin@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=sebastian.krebs.berlin@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.42 as permitted sender) X-PHP-List-Original-Sender: sebastian.krebs.berlin@googlemail.com X-Host-Fingerprint: 209.85.214.42 mail-bw0-f42.google.com Received: from [209.85.214.42] ([209.85.214.42:49478] helo=mail-bw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/00-12367-680A84E4 for ; Mon, 15 Aug 2011 00:28:55 -0400 Received: by bkd19 with SMTP id 19so2875491bkd.29 for ; Sun, 14 Aug 2011 21:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=T+3u48x9V95/92aA7n5SG3aMCBWsyHSX9FRfVJJEyck=; b=OAwKbZJzH8AIhkyiqcJOkQTB/9oPcDjGQpZISWpgKILrEYhraI733lqevfJYdbiIdP lyDGpykswxGa975cN2Af8BTVsj6040xX3VJ1Tove0rOHTlBZ6AK7GS4hMOoeARGL8NfO Fq6WhR9vGzjoFyZUovlZKbMDgc8EYDOij7K48= Received: by 10.204.232.144 with SMTP id ju16mr691418bkb.124.1313382531515; Sun, 14 Aug 2011 21:28:51 -0700 (PDT) Received: from [192.168.24.2] (91-64-205-130-dynip.superkabel.de [91.64.205.130]) by mx.google.com with ESMTPS id a22sm1433075bke.20.2011.08.14.21.28.49 (version=SSLv3 cipher=OTHER); Sun, 14 Aug 2011 21:28:49 -0700 (PDT) Message-ID: <4E48A081.2080300@googlemail.com> Date: Mon, 15 Aug 2011 06:28:49 +0200 Reply-To: sebastian.krebs.berlin@googlemail.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: internals@lists.php.net References: <4E48121A.3090007@sugarcrm.com> <4E48134E.4030708@sugarcrm.com> <4E481695.6040900@php.net> <4E483804.7070009@sugarcrm.com> <4E484037.2080107@php.net> <4E4843B0.70605@php.net> In-Reply-To: <4E4843B0.70605@php.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE]strn(case)cmp supporting a negative length as its third paramter From: sebastian.krebs.berlin@googlemail.com (Sebastian Krebs) Am 14.08.2011 23:52, schrieb Rasmus Lerdorf: > On 08/14/2011 02:37 PM, Rasmus Lerdorf wrote: >> On 08/14/2011 02:03 PM, Stas Malyshev wrote: >>> Hi! >>> >>> On 8/14/11 11:40 AM, Rasmus Lerdorf wrote: >>>> My main issue with changing strncmp/strncasecmp is that these are >>>> currently exact mappings of the underlying libc functions. For people >>> >>> And why should anybody care? 99% of people using PHP never used a libc >>> function and can hardly tell libc from gcc. If we can extend this >>> function with useful functionality, nobody cares about what libc does. >>> >>>> For example, I could imagine people writing code along these lines: >>>> >>>> $len = strlen($user_data) - strlen($suffix); >>>> if(!strncmp($user_data, $string, $len)) { >>>> // do something >>>> } >>> >>> Warning doesn't fix the bug - and unless you're in 0.0001% of the >>> population that actually reads the logs daily and checks every message >>> there it would be little to help you. We should have more useful >>> functions, not more warnings. Warning won't make this code to work. >> >> I agree, however this change would potentially change the return value >> of the function. Before it would warn and not match. Even if you never >> saw the warning, at least length -1 would not give you a match. Now if >> the user data happens to end with the right character we now have a >> string match which is not at all what the code was written to do. > > Put more succinctly. Subtle BC breaks like this worry me. Any strncmp() > call with a computed length where that length may in some cases go > negative will now potentially return a match where it wouldn't before. > This would be very hard to track down. And the reason for introducing > this subtle BC break is so that you can rewrite: > > if (substr("prefix_num", -3) == "num") { > echo "they have same suffix\n"; > } > > > into: > > if (strncmp("prefix_num", "num", -3) === 0) { > echo "they have same suffix\n"; > } > > That doesn't seem like a big win to me. Or just if (strncmp(strrev('prefix_num'), 'mun', 3) === 0) { // do something } > > -Rasmus > Regards, Sebastian