linux-kernel - Re: [PATCH v1 1/8] lib/string: introduce match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VdBSnn+X41JZprX++a29yaSp49YB1DY2bv89ORzhOr3CA@mail.gmail.com>
Date:	Tue, 12 Jan 2016 00:24:36 +0200
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Tejun Heo <tj@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	David Airlie <airlied@...ux.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH v1 1/8] lib/string: introduce match_string() helper

On Tue, Jan 12, 2016 at 12:10 AM, Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
> On Mon, Jan 11 2016, Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
>
>> On Sat, 2016-01-09 at 13:57 +0200, Andy Shevchenko wrote:
>>> On Sat, Jan 9, 2016 at 3:12 AM, Sergey Senozhatsky
>>> <sergey.senozhatsky@...il.com> 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