On 08/08/2021 01:16, 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. Seems very important to check.. there are lots of standards that require checking such things. eg ISO 26262 Functional Safety Standard I know we all know already that many bugs are caused by overruns. A NULL ptr dereference would crash the software. That's a kind of DoS. Just imagine someone connects a USB device (or any other different) which has a badly formed string, that is not NUL terminated. Or even gets a pointer from HW that is NULL. Unless we check the pointer, the string, we won't know. Typically it will be fine, until it isn't. Users don't want a core dump, they don't want to file a bug report. It's easy enough just to check it is what we expect. We also check numbers are not zero when dividing by a number to avoid SIGFPE when that number came from an external place outside our module. Cheers, Jonny
