* memchr() vs. memscan()
@ 2023-02-02 15:34 Andy Shevchenko
2023-02-03 7:18 ` Rasmus Villemoes
0 siblings, 1 reply; 2+ messages in thread
From: Andy Shevchenko @ 2023-02-02 15:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Rasmus Villemoes, Kees Cook
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: memchr() vs. memscan()
2023-02-02 15:34 memchr() vs. memscan() Andy Shevchenko
@ 2023-02-03 7:18 ` Rasmus Villemoes
0 siblings, 0 replies; 2+ messages in thread
From: Rasmus Villemoes @ 2023-02-03 7:18 UTC (permalink / raw)
To: Andy Shevchenko, linux-kernel; +Cc: Kees Cook
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-02-03 7:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-02 15:34 memchr() vs. memscan() Andy Shevchenko
2023-02-03 7:18 ` Rasmus Villemoes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.