Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1303510 > unrolled thread
| Started by | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| First post | 2016-01-07 13:10 +0100 |
| Last post | 2016-01-12 09:30 +0100 |
| Articles | 3 on this page of 23 — 9 participants |
Back to article view | Back to linux.kernel
[PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
[PATCH v1 8/8] ide: hpt366: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
[PATCH v1 2/8] device property: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
Re: [PATCH v1 2/8] device property: convert to use match_string() helper Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-01-08 14:10 +0100
[PATCH v1 6/8] power: ab8500: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
Re: [PATCH v1 6/8] power: ab8500: convert to use match_string() helper Linus Walleij <linus.walleij@linaro.org> - 2016-01-07 16:20 +0100
[PATCH v1 7/8] ata: hpt366: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
Re: [PATCH v1 7/8] ata: hpt366: convert to use match_string() helper Tejun Heo <tj@kernel.org> - 2016-01-07 16:50 +0100
[PATCH v1 5/8] power: charger_manager: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
[PATCH v1 4/8] drm/edid: convert to use match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 13:10 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-01-07 14:10 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-07 14:20 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-01-07 14:30 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-01-07 23:10 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-08 09:50 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-08 01:20 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-08 09:50 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-01-09 02:20 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-01-09 13:00 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-01-11 16:00 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-01-11 23:20 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-01-11 23:30 +0100
Re: [PATCH v1 1/8] lib/string: introduce match_string() helper Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-01-12 09:30 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Rasmus Villemoes <linux@rasmusvillemoes.dk> |
|---|---|
| Date | 2016-01-11 23:20 +0100 |
| Message-ID | <qPSYG-bV-3@gated-at.bofh.it> |
| In reply to | #1306361 |
On Mon, Jan 11 2016, Andy Shevchenko <andriy.shevchenko@linux.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@gmail.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".
Rasmus
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2016-01-11 23:30 +0100 |
| Message-ID | <qPT8n-gV-39@gated-at.bofh.it> |
| In reply to | #1306765 |
On Tue, Jan 12, 2016 at 12:10 AM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On Mon, Jan 11 2016, Andy Shevchenko <andriy.shevchenko@linux.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@gmail.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
[toc] | [prev] | [next] | [standalone]
| From | Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> |
|---|---|
| Date | 2016-01-12 09:30 +0100 |
| Message-ID | <qQ2v0-6Gt-7@gated-at.bofh.it> |
| In reply to | #1306765 |
Hello,
On (01/11/16 23:10), Rasmus Villemoes wrote:
[..]
> > 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;
> > }
may be later this week; I'm a bit out of spare time at the moment.
> Yeah, a separate function is probably better. But why not a more
> explicit name, match_prefix, match_string_prefix, match_string_starts?
Not married to nmatch_string(), but at the same time, IMHO, *_prefix or
*_starts naming is not really better. One can pass a string with offset,
e.g.
FOO_starts(array, array_size, string + offset, strlen(string) - offset)
which will be equivalent to FOO_ends(), but not FOO_starts() or FOO_prefix().
Personally, I'd prefer to preserve strcmp/strncmp semantics, thus, forbidding
`len < 0' case, which looks cryptic to me.
> 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);
if this is a dynamic array, then there should be some function that
fills in that array, so having a simple bool flag in the code will
suffice; if this is a static array, then ARRAY_SIZE() should do the
trick. I would never expect a string matching function to have this
type of functionality, TBH.
But the question is
> is the empty string a prefix of some array element
do people really need this?
the way I see it, the idea is to have wrappers around
while (array[..]) if strcmp()/strncmp() == 0 break ...
both of which [strcmp()/strncmp()] have a well known and expected
semantics, changing this can only confuse people.
-ss
> 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
>
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web