Re: [hnaz-linux-mm:master 156/523] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy'

[Daniel Axtens <dja@axtens.net>]

> 		inqdata[0] = TYPE_PROCESSOR;
> 		/* Periph Qualifier & Periph Dev Type */
> 		inqdata[1] = 0;
> 		/* rem media bit & Dev Type Modifier */
> 		inqdata[2] = 0;
> 		/* ISO, ECMA, & ANSI versions */
> 		inqdata[4] = 31;
> 		/* length of additional data */
> 		strncpy(&inqdata[8], "Areca   ", 8);
> 		/* Vendor Identification */
>>>>		strncpy(&inqdata[16], "RAID controller ", 16);
> 		/* Product Identification */
> 		strncpy(&inqdata[32], "R001", 4); /* Product Revision */


> That strncpy() will indeed fail to copy the trailing null, but it looks
> like that null isn't appropriate in the inquiry data.
>
> So I suspect this is a valid usage of strncpy() and the checking is
> just too strict.
>
> otoh if this is the only place where we hit this issue then perhaps we
> can switch to memcpy() and get on with life ;)

Hmm, yes, I think you're right and gcc is being a bit ambitious here -
although I can understand the warning given that the behaviour relied
upon here is rarely going to be what the developer intendend!

We could build the file with -Wno-stringop-truncation, but I do wonder
if memcpy might make the semantics more obvious...

Regards,
Daniel