Bug 21018 - Add memcchr function
Summary: Add memcchr function
Status: RESOLVED DUPLICATE of bug 19920
Alias: None
Product: glibc
Classification: Unclassified
Component: string (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2017-01-02 21:04 UTC by Yuri Gribov
Modified: 2017-01-25 15:15 UTC (History)
5 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Gribov 2017-01-02 21:04:27 UTC
Recent FreeBSD have a nice complement for standard memchr function - memcchr (https://www.freebsd.org/cgi/man.cgi?query=memcchr). It e.g. allows user to efficiently check whether buffer is zeroed out. Would it make sense to add something like this to Glibc as well (yes, I can volunteer)?

Here's a motivational GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 (which also references stackoverflow proving that problem is not that uncommon).
Comment 1 Adhemerval Zanella 2017-01-04 12:24:17 UTC
I am still skeptical how common this specific function is based solely on stackoverflow reports.  FreeBSD usage itself seems not really widespread and only occurs in basically two places [1] (it does not invalidate the possible usefulness of the symbol, but show that it usage might be somewhat limited).

Also, it does not seems to be reimplemented in many places (not at least with same name) on other projects [2].

If you want to pursuit the possible inclusion on glibc, I would recommend start a discussion on libc-alpha maillist.

[1] https://github.com/freebsd/freebsd/search?utf8=%E2%9C%93&q=memcchr
[2] https://codesearch.debian.net/search?q=memcchr
Comment 2 Yuri Gribov 2017-01-13 07:54:45 UTC
Posted RFC in libc-alpha: https://sourceware.org/ml/libc-alpha/2017-01/msg00264.html
Comment 3 Paul Eggert 2017-01-13 16:15:35 UTC
The FreeBSD memcchr is a kernel function, not a C library function, so it's not really a precedent.

I've seen similar functions in application code (e.g., all_zeros in grep/src/grep.c, zero_block_p in src/tar/sparse.c). The functions are easy to write, not likely to be wrong, and not a performance bottleneck since they are typically applied to input data and the cost of input dwarfs the cost of running the function. Since these functions would need to be retained in the source code anyway (which needs to be portable to non-glibc systems) from an application viewpoint there doesn't seem to be much advantage to adding this functionality to the glibc API.
Comment 4 Yuri Gribov 2017-01-14 05:13:59 UTC
Closing as dup.

*** This bug has been marked as a duplicate of bug 19920 ***