From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Tejun Heo <tj@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
David Airlie <airlied@linux.ie>,
Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [PATCH v1 1/8] lib/string: introduce match_string() helper
Date: Tue, 12 Jan 2016 17:26:49 +0900 [thread overview]
Message-ID: <20160112082649.GA1821@swordfish> (raw)
In-Reply-To: <8760yzbwd5.fsf@rasmusvillemoes.dk>
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
>
prev parent reply other threads:[~2016-01-12 8:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 12:06 [PATCH v1 1/8] lib/string: introduce match_string() helper Andy Shevchenko
2016-01-07 12:06 ` [PATCH v1 2/8] device property: convert to use " Andy Shevchenko
2016-01-08 13:01 ` Mika Westerberg
2016-01-07 12:06 ` [PATCH v1 3/8] pinctrl: " Andy Shevchenko
2016-01-07 15:19 ` Linus Walleij
2016-01-07 12:06 ` [PATCH v1 4/8] drm/edid: " Andy Shevchenko
2016-01-07 12:06 ` [PATCH v1 5/8] power: charger_manager: " Andy Shevchenko
2016-01-07 12:06 ` [PATCH v1 6/8] power: ab8500: " Andy Shevchenko
2016-01-07 15:19 ` Linus Walleij
2016-01-07 12:06 ` [PATCH v1 7/8] ata: hpt366: " Andy Shevchenko
2016-01-07 15:44 ` Tejun Heo
2016-01-07 12:06 ` [PATCH v1 8/8] ide: " Andy Shevchenko
2016-01-07 13:07 ` [PATCH v1 1/8] lib/string: introduce " Heikki Krogerus
2016-01-07 13:12 ` Andy Shevchenko
2016-01-07 13:24 ` Heikki Krogerus
2016-01-07 22:05 ` Rasmus Villemoes
2016-01-08 8:40 ` Andy Shevchenko
2016-01-08 0:13 ` Sergey Senozhatsky
2016-01-08 8:43 ` Andy Shevchenko
2016-01-09 1:12 ` Sergey Senozhatsky
2016-01-09 11:57 ` Andy Shevchenko
2016-01-11 15:00 ` Andy Shevchenko
2016-01-11 22:10 ` Rasmus Villemoes
2016-01-11 22:24 ` Andy Shevchenko
2016-01-12 8:26 ` Sergey Senozhatsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160112082649.GA1821@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=davem@davemloft.net \
--cc=dbaryshkov@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).