As per POSIX, when str{,r}chr is comparing it should convert c to a char.

The C implementation of str{,r}chr are not linked to the build, because
assembly implementations are used, but change to code for easier reference.
At least the i386 and amd64 are checked and seem to do the correct thing.

Found thanks to the csh any/strchr change.

minor pointers and OK millert@

1 files changed, 3 insertions, 2 deletions

diff --git a/src/lib/libc/string/strchr.3 b/src/lib/libc/string/strchr.3
index 854438677a..07e7f29f5b 100644
--- a/src/lib/libc/string/strchr.3
+++ b/src/lib/libc/string/strchr.3
@@ -1,4 +1,4 @@
-.\"     $OpenBSD: strchr.3,v 1.12 2015/11/24 09:14:35 daniel Exp $
+.\"     $OpenBSD: strchr.3,v 1.13 2018/10/01 06:37:37 martijn Exp $
 .\"
 .\" Copyright (c) 1990, 1991 The Regents of the University of California.
 .\" All rights reserved.
@@ -31,7 +31,7 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: November 24 2015 $
+.Dd $Mdocdate: October 1 2018 $
 .Dt STRCHR 3
 .Os
 .Sh NAME
@@ -50,6 +50,7 @@ The
 .Fn strchr
 function locates the first occurrence of the character
 .Fa c
+.Pq converted to a char
 in the string
 .Fa s .
 The terminating NUL character is considered part of the string.