From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933337AbcAKWYj (ORCPT ); Mon, 11 Jan 2016 17:24:39 -0500 Received: from mail-yk0-f181.google.com ([209.85.160.181]:34020 "EHLO mail-yk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933186AbcAKWYh (ORCPT ); Mon, 11 Jan 2016 17:24:37 -0500 MIME-Version: 1.0 In-Reply-To: <8760yzbwd5.fsf@rasmusvillemoes.dk> References: <1452242596.30729.425.camel@linux.intel.com> <20160109011241.GB560@swordfish> <1452524400.26146.32.camel@linux.intel.com> <8760yzbwd5.fsf@rasmusvillemoes.dk> Date: Tue, 12 Jan 2016 00:24:36 +0200 Message-ID: Subject: Re: [PATCH v1 1/8] lib/string: introduce match_string() helper From: Andy Shevchenko To: Rasmus Villemoes Cc: Andy Shevchenko , Sergey Senozhatsky , Tejun Heo , Linus Walleij , Dmitry Eremin-Solenikov , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "David S. Miller" , David Airlie , Andrew Morton , Sergey Senozhatsky Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2016 at 12:10 AM, Rasmus Villemoes wrote: > On Mon, Jan 11 2016, Andy Shevchenko wrote: > >> On Sat, 2016-01-09 at 13:57 +0200, Andy Shevchenko wrote: >>> On Sat, Jan 9, 2016 at 3:12 AM, Sergey Senozhatsky >>> wrote: >>> > Andy Shevchenko wrote: >>> > [..] >>> > > > >>> > > > strncmp() case seems to be quite common. >>> > > >>> > > Like I answered to Rasmus, please, provide real examples. >>> > >>> > [..] >>> > > > int nmatch_string(array, array_size, string, string_len) >>> > > > { >>> > > > do { >>> > > > strncmp(); >>> > > > } while (); >>> > > > } >>> > > > >>> > > > int match_string(array, array_size, string) >>> > > > { >>> > > > return nmatch_string(array, array_size, string, >>> > > > strlen(string)); >>> > > > } >>> > > >>> > > See above. >>> > >>> > after some quick and inaccurate grepping, well, probably you're >>> > right - not worth it. >>> >>> Good grep anyway, it clearly shows that there is hard to generalize >>> which limit to use: a) length of a first argument / item from a list, >>> b) length of a second argument or a constant. >>> >>> > arch/mips/bcm63xx/boards/board_bcm963xx.c void __init >>> > board_prom_init(void) >>> > net/irda/irnet/irnet_irda.c irnet_dname_to_daddr() >>> > arch/powerpc/sysdev/ppc4xx_cpm.c static ssize_t cpm_idle_store() >>> > arch/x86/ras/mce_amd_inj.c static int __set_inj >>> > drivers/hwtracing/intel_th/msu.c mode_store >>> > drivers/pci/pcie/aer/ecrc.c void pcie_ecrc_get_policy >>> > drivers/pci/pcie/aspm.c pcie_aspm_set_policy >>> > drivers/scsi/aic7xxx/aic7xxx_osm.c aic7xxx_setup >>> > drivers/scsi/aic7xxx/aic79xx_osm.c aic79xx_setup >>> > drivers/scsi/scsi_transport_fc.c static int get_fc_##title##_match >>> > drivers/staging/android/ion/hisilicon/hi6220_ion.c get_type_by_name >>> > drivers/staging/lustre/lustre/lmv/lproc_lmv.c placement_name2policy >>> > drivers/xen/sys-hypervisor.c pmu_mode_store >> >> Thought more about those cases. >> >> If you would like you may introduce something like >> >> int nmatch_string(array, array_size, string, int len) >> { >> if (len < 0) >> return match_string(); >> >> for (...) { >> size_t itemlen = (len > 0) ? len : strlen(array[index]); >> ... >> if (!strncmp(array[index], string, itemlen)) >> return index; >> } >> return -EINVAL; >> } > > Yeah, a separate function is probably better. But why not a more > explicit name, match_prefix, match_string_prefix, match_string_starts? > > I like the idea of passing the string length if one wants the "is this a > prefix of some array element" semantics, and a sentinel otherwise. But I > don't see any case where one would want match_string() semantics (why > not call match_string directly instead?), so why not let len < 0 mean > "is some array element a prefix of this string" and "len >= 0" be the > other case. I don't see why one shouldn't be able to ask "is the empty > string a prefix of some array element" (that is, are there any elements > in the array); both the array and the string might be run-time things, > so this could occur. And it's not up to a generic library routine like > this to impose restrictions like "the empty string makes no sense, go > away". I have no strong feelings to my initial proposal, and your suggestions sound sane. Unfortunately I have no time to properly implement it and convert users, so, if Sergey would like to do that, I will no object. -- With Best Regards, Andy Shevchenko