Message-ID: <f484c11b-a221-b096-7ae6-91de7490b8a0@rasmusvillemoes.dk>
Date:   Fri, 3 Feb 2023 08:18:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: memchr() vs. memscan()
Content-Language: en-US, da
To:     Andy Shevchenko <andriy.shevchenko@intel.com>,
        linux-kernel@vger.kernel.org
Cc:     Kees Cook <keescook@chromium.org>
References: <Y9vX95GpI272VKn0@smile.fi.intel.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <Y9vX95GpI272VKn0@smile.fi.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 02/02/2023 16.34, Andy Shevchenko wrote:
> Why do we have memchr() and memscan() implementations in lib/string.c?
> As far as I can see the one may be derived from the other easily.

Well, memchr() is the C standard thing, and the one arches are more
likely to (and do) provide custom implementations of. memscan() seems to
be to memchr() as strchrnul() is to strchr(), and judging by the number
of callers, I don't think any optimizations or a separate C
implementation is really worth it. So yes, by all means we can replace
its entire body by

  return memchr(addr, c, size) ?: addr + size;

That's possibly even a win for the arches that do provide their own
memchr(), but again, performance of this one doesn't matter at all. But
the tiny kernel folks might appreciate this.

Rasmus