From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Tejun Heo <tj@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
linux-kernel@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>
Subject: Re: [PATCH v1 1/8] lib/string: introduce match_string() helper
Date: Fri, 08 Jan 2016 10:40:51 +0200 [thread overview]
Message-ID: <1452242451.30729.422.camel@linux.intel.com> (raw)
In-Reply-To: <874mepnizu.fsf@rasmusvillemoes.dk>
On Thu, 2016-01-07 at 23:05 +0100, Rasmus Villemoes wrote:
> On Thu, Jan 07 2016, Andy Shevchenko <andriy.shevchenko@linux.intel.c
> om> wrote:
>
> > From time to time we have to match a string in an array. Make a
> > simple helper
> > for that purpose.
> > /**
> > + * match_string - matches given string in an array
> > + * @array: array of strings
> > + * @len: number of strings in the array or 0 for NULL
> > terminated arrays
> > + * @string: string to match with
> > + *
> > + * Return:
> > + * index of a @string in the @array if matches, or %-ENODATA
> > otherwise.
> > + */
> > +int match_string(const char * const *array, size_t len, const char
> > *string)
> > +{
> > + int index = 0;
> > + const char *item;
> > +
> > + do {
> > + item = array[index];
> > + if (!item)
> > + break;
> > + if (!strcmp(item, string))
> > + return index;
> > + } while (++index < len || !len);
> > +
> > + return -ENODATA;
> > +}
> > +EXPORT_SYMBOL(match_string);
> > +
>
> I'd suggest making it -1 (which, since len is a size_t, is
> effectively
> infinity) having the meaning "the array is terminated by a NULL
> entry". match_string(..., ARRAY_SIZE(my_array), ...) will break if
> the
> array happens to be empty, which could e.g. happen in a case like
>
> const char *my_array[] = {
> #ifdef CONFIG_THIS
> "this",
> #endif
> #ifdef CONFIG_THAT
> "that",
> #endif
> };
It might make sense, though I don't remember current users with such
conditions.
> I also think the condition/loop above is unreadable.
Hmm… For me looks straightforward.
>
> for (index = 0; index < len; index++) {
> ...
> }
>
> is much clearer.
If we switch to -1, it will look indeed simpler.
>
> Why -ENODATA and not just -1? It is rather unlikely that anyone would
> pass on that particular -Exxx value. Not a biggie, just curious.
There are few of users already that would like to return error code to
upper level. In some cases better to have
return match_string();
than
ret = match_string();
if (ret < 0)
return -EFOO;
return 0;
And returning -ENODATA doesn't prevent to have latter, but allows
former.
>
> Would there be more potential users if we had a flag argument
> allowing
> case-insensitive matching? Would there be more potential users if a
> flag
> allowed to ask whether the given string is a _prefix_ of one of the
> strings in the array, or vice versa? Something like
>
> #define MATCH_STRING_CASE 0x01
> #define MATCH_STRING_PREFIX_OF_ARRAY_ELEM 0x02 /* yeah, that name
> sucks */
> #define MATCH_ARRAY_ELEM_PREFIX_OF_STRING 0x04 /* this too */
>
> int match_string(const char * const *array, size_t len, const char
> *string, unsigned flags)
> {
> #define MATCH_PREFIX (MATCH_... | MATCH_...)
> int index;
> const char *item;
> int (*match_func)(const char *, const char *) =
> flags & MATCH_STRING_CASE ? strcasecmp : strcmp;
> int (*prefix_func)(const char *, const char *, size_t) =
> flags & MATCH_STRING_CASE ? strncasecmp : strncmp;
>
> for (index = 0; index < len; ++index) {
> item = array[index];
> if (!item)
> break;
> if (flags & MATCH_PREFIX) {
> size_t len = strlen(flags &
> MATCH_STRING_PREFIX_OF_ARRAY_ELEM ?
> string : item);
> if (!prefix_func(item, string, len))
> return index;
> } else if (!match_func(item, string)) {
> return index;
> }
> }
> return -1;
> }
>
> (Ok, it's not that pretty; maybe it'd be better to use
> switch(flags&MATCH_PREFIX) {}. Or maybe just the case-insensitive
> part
> is worth keeping; in that case the above isn't that bad.)
I won't overcomplicate it until we have enough users to consider. Any
examples where we need this?
And I prefer way to have different prototypes for them instead of net
of conditions.
Thanks for review. I will send v3 (yeah, this is actually v2) with
change you proposed in the first part. For the second one I would like
to have real examples before doing anything.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2016-01-08 8:40 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 [this message]
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
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=1452242451.30729.422.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--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=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).