On Mon, Sep 06, 2021 at 09:49:23PM +0800, Jason Wang wrote: > The strlcpy should not be used because it doesn't limit the source > length. As linus says, it's a completely useless function if you > can't implicitly trust the source string - but that is almost always > why people think they should use it! All in all the BSD function > will lead some potential bugs. > > But the strscpy doesn't require reading memory from the src string > beyond the specified "count" bytes, and since the return value is > easier to error-check than strlcpy()'s. In addition, the implementation > is robust to the string changing out from underneath it, unlike the > current strlcpy() implementation. > > Thus, We prefer using strscpy instead of strlcpy. > > Signed-off-by: Jason Wang <wangborong@xxxxxxxxxx> > --- > arch/mips/bcm47xx/board.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/mips/bcm47xx/board.c b/arch/mips/bcm47xx/board.c > index 35266a70e22a..74113dcd86e0 100644 > --- a/arch/mips/bcm47xx/board.c > +++ b/arch/mips/bcm47xx/board.c > @@ -345,7 +345,7 @@ void __init bcm47xx_board_detect(void) > > board_detected = bcm47xx_board_get_nvram(); > bcm47xx_board.board = board_detected->board; > - strlcpy(bcm47xx_board.name, board_detected->name, > + strscpy(bcm47xx_board.name, board_detected->name, > BCM47XX_BOARD_MAX_NAME); > } > > -- > 2.33.0 applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
