From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761471AbcAKWKy (ORCPT ); Mon, 11 Jan 2016 17:10:54 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37044 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761443AbcAKWKu convert rfc822-to-8bit (ORCPT ); Mon, 11 Jan 2016 17:10:50 -0500 From: Rasmus Villemoes To: Andy Shevchenko 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 Subject: Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Organization: D03 References: <1452242596.30729.425.camel@linux.intel.com> <20160109011241.GB560@swordfish> <1452524400.26146.32.camel@linux.intel.com> X-Hashcash: 1:20:160111:andy.shevchenko@gmail.com::VAJV+rgFliJtlVb+:0000000000000000000000000000000000001JCh X-Hashcash: 1:20:160111:airlied@linux.ie::MJ+6D+2uzaaR2SI3:0117C X-Hashcash: 1:20:160111:linux-kernel@vger.kernel.org::s8K2j+bC1xCD5dux:0000000000000000000000000000000001ZvK X-Hashcash: 1:20:160111:akpm@linux-foundation.org::GReBBdB0VxMbLv88:0000000000000000000000000000000000002ErW X-Hashcash: 1:20:160111:davem@davemloft.net::FvkQuDIUYjbTsHpH:00000000000000000000000000000000000000000034sY X-Hashcash: 1:20:160111:dbaryshkov@gmail.com::0goUHRHg++AWp536:000000000000000000000000000000000000000003eh4 X-Hashcash: 1:20:160111:linux-pm@vger.kernel.org::uEPbvQrGRwEMUGEU:00000000000000000000000000000000000004NTs X-Hashcash: 1:20:160111:andriy.shevchenko@linux.intel.com::ohpDTyarPL/fwfvT:00000000000000000000000000004rMZ X-Hashcash: 1:20:160111:sergey.senozhatsky@gmail.com::hQViFJymLZ/EGvT1:0000000000000000000000000000000005SxY X-Hashcash: 1:20:160111:sergey.senozhatsky.work@gmail.com::7ozhH0DAleGMkFJJ:000000000000000000000000000055SN X-Hashcash: 1:20:160111:tj@kernel.org::2bpm8/adEAUHg5aB:00006v6X X-Hashcash: 1:20:160111:linus.walleij@linaro.org::HoVKjkMH01fx/jn1:00000000000000000000000000000000000007wIQ Date: Mon, 11 Jan 2016 23:10:46 +0100 In-Reply-To: <1452524400.26146.32.camel@linux.intel.com> (Andy Shevchenko's message of "Mon, 11 Jan 2016 17:00:00 +0200") Message-ID: <8760yzbwd5.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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". Rasmus