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