[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150206175549.117804c2@gandalf.local.home>
Date: Fri, 6 Feb 2015 17:55:49 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Al Viro <viro@...IV.linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH v2 2/7] implement memmem()
On Fri, 06 Feb 2015 23:30:19 +0100
Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> On Fri, Feb 06 2015, Al Viro <viro@...IV.linux.org.uk> wrote:
>
> > +/**
> > + * strnstr - Find the first substring in a length-limited string
> > + * @s1: The string to be searched
> > + * @s2: The string to search for
> > + * @len: the maximum number of characters to search
> > + */
> > +char *strnstr(const char *s1, const char *s2, size_t len)
> > +{
> > + return memmem(s1, len, s2, strlen(s2));
> > +}
>
> Most strn* interfaces don't require the n to be at most the actual
> string length, but it seems that this would happily search past the '\0'
> of s1 if len is large enough, e.g.
>
> strnstr("abc\0def", "def", 1000)
>
> will not return NULL (unlike what the libbsd version does). So either
> that restriction should be documented or len should be replaced by
> min(len, strlen(s1)).
The version that is currently in the kernel will do exactly what the
patched version will do. Although it may be different than what libbsd
might do, we don't really care. The kernel doc states that @len will be
the maximum number of characters to search, and that's exactly what
this does.
The functionality of strnstr() does not change with this patch, so it
does not need to address your concern.
Feel free to submit a patch that states the difference of the kernel
version of strnstr with whatever version is out in the wild. But that
is out of scope with this series.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists