summaryrefslogtreecommitdiffstats
path: root/lib/kfifo.c
diff options
context:
space:
mode:
authorPeter Rosin <peda@axentia.se>2019-07-16 16:27:15 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2019-07-16 19:23:22 -0700
commitb09757104e433447226a95eff4b92583acc0b0fb (patch)
tree35e349432b94a5351aa5dc958b40f3dd337ac897 /lib/kfifo.c
parent4c6080cd6f8baad9f7faa3deac9a90e59726b119 (diff)
downloadlinux-b09757104e433447226a95eff4b92583acc0b0fb.tar.gz
linux-b09757104e433447226a95eff4b92583acc0b0fb.tar.bz2
linux-b09757104e433447226a95eff4b92583acc0b0fb.zip
lib/string.c: allow searching for NUL with strnchr
Patch series "lib/string: search for NUL with strchr/strnchr". I noticed an inconsistency where strchr and strnchr do not behave the same with respect to the trailing NUL. strchr is standardised and the kernel function conforms, and the kernel relies on the behavior. So, naturally strchr stays as-is and strnchr is what I change. While writing a few tests to verify that my new strnchr loop was sane, I noticed that the tests for memset16/32/64 had a problem. Since it's all about the lib/string.c file I made a short series of it all... This patch (of 3): strchr considers the terminating NUL to be part of the string, and NUL can thus be searched for with that function. For consistency, do the same with strnchr. Link: http://lkml.kernel.org/r/20190506124634.6807-2-peda@axentia.se Signed-off-by: Peter Rosin <peda@axentia.se> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/kfifo.c')
0 files changed, 0 insertions, 0 deletions