Hi Alex, On 8/8/21 2:16 AM, Alejandro Colomar (man-pages) wrote: > Hi, Michael! > > On 8/8/21 1:45 AM, Michael Kerrisk (man-pages) wrote: >> Hello Alex, >> >> I see there was a rather long mail thread that led >> to this patch. The patch definitely deserves a commit >> message. >> >> See also below. >> On 7/28/21 10:20 PM, Alejandro Colomar wrote: >>> Reported-by: Jonny Grant <jg@xxxxxxxx> >>> Signed-off-by: Alejandro Colomar <alx.manpages@xxxxxxxxx> >>> --- >>> man3/strlen.3 | 6 ++++++ >>> man3/wcslen.3 | 9 ++++++++- >>> 2 files changed, 14 insertions(+), 1 deletion(-) >>> >>> diff --git a/man3/strlen.3 b/man3/strlen.3 >>> index dea4c1050..78783c446 100644 >>> --- a/man3/strlen.3 >>> +++ b/man3/strlen.3 >>> @@ -66,6 +66,12 @@ T} Thread safety MT-Safe >>> .sp 1 >>> .SH CONFORMING TO >>> POSIX.1-2001, POSIX.1-2008, C89, C99, C11, SVr4, 4.3BSD. >>> +.SH NOTES >>> +.SS strnlen(3) >>> +If the input buffer size is known, >>> +it is probably better to use >>> +.BR strnlen (3), >>> +which can prevent reading past the end of the array. >> >> I hesitate slightly about this. strlen() is in the C standard, but >> strnlen() is not. What do you think; do we need to care? > > I have some doubts about this patch, but in a completely different sense: > > I don't know if I'm being a bit paranoid in treating user input. I've > always been taught that I should program deffensively, but as time > passes by, I realize myself that I was programming too much > deffensively, and even introducing bugs in the error handling code. And > in many cases, strings will always be NUL-terminated, so maybe I'm just > passing around a wrong recommendation. > > What do you think about this? How about a sentence something like: [[ In cases where the input buffer may not contain a terminating null byte, .BR strnlen (3) should be used instead. ]] What do you think? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
