Re: [PATCH V2] auxdisplay: use correct string length

[Willy Tarreau]

On Tue, Feb 13, 2018 at 09:19:21AM +0800, Xiongfeng Wang wrote:
> >> diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
> >> index ea7869c..d288900 100644
> >> --- a/drivers/auxdisplay/panel.c
> >> +++ b/drivers/auxdisplay/panel.c
> >> @@ -1506,10 +1506,10 @@ static struct logical_input *panel_bind_key(const char *name, const char *press,
> >>         key->rise_time = 1;
> >>         key->fall_time = 1;
> >>
> >> -       strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> >> -       strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> >> +       strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str) - 1);
> >> +       strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str) - 1);
> >>         strncpy(key->u.kbd.release_str, release,
> >> -               sizeof(key->u.kbd.release_str));
> >> +               sizeof(key->u.kbd.release_str) - 1);
> > 
> > Are you sure about this patch? `kbd` says "strings can be non null-terminated".
> > 
> > Willy, maybe those should just be memcpy()s? (unless the remaining
> > bytes, if any, must be 0).
> Sorry, my apologies. I think I made a mistake. I meant to use strlcpy(), but this
> also decrease the destination storage size by one.
> I think, if the strings can be non null-terminated,  we can just use memcpy().

Well, memcpy() needs as much data in as out. strncpy() does exactly what was
apparently needed there : take at most X chars from a given string, and write
exactly X on the output, possibly padding with zeroes. We sure can stop using
strncpy() and reimplement it, but that becomes ridiculous. One day gcc will
tell us that an "if" statement misses an "else" which is probably an error
and we'll have to put "else dummy();" everywhere in the code to calm it.

> This may suppress the gcc warning.

In fact there are two big problems with gcc warnings :
  - writing -Wno-something-unknown triggers an error on versions where
    "something-unknown" isn't known, making it difficult to permanently
    disable warnings (though in the kernel we handle this pretty fine)

  - warnings and diagnostics are conflated. Some warnings should only be
    provided when the developer explicitly asks for suspicious stuff
    (-Wsecurity, -Wsuspicious, etc) that would *not* be part of -Wall
    since -Wall is usually used to report real warnings.

My preferred one today is the one by which gcc reads your *comments* to
figure whether you forgot a break in a case statement...

Regards,
Willy