Building libfc with gcc -Warray-bounds identifies a number of cases in one
file where a strncpy() is performed into a single-byte character array:

In file included from include/linux/bitmap.h:9,
                 from include/linux/cpumask.h:12,
                 from include/linux/smp.h:13,
                 from include/linux/lockdep.h:14,
                 from include/linux/spinlock.h:59,
                 from include/linux/debugobjects.h:6,
                 from include/linux/timer.h:8,
                 from include/scsi/libfc.h:11,
                 from drivers/scsi/libfc/fc_elsct.c:17:
In function 'strncpy',
    inlined from 'fc_ct_ms_fill.constprop' at drivers/scsi/libfc/fc_encode.h:235:3:
include/linux/string.h:290:30: warning: '__builtin_strncpy' offset [56, 135] from the object at 'pp' is out of the bounds of referenced subobject 'value' with type '__u8[1]' {aka 'unsigned char[1]'} at offset 56 [-Warray-bounds]
  290 | #define __underlying_strncpy __builtin_strncpy
      |                              ^
include/linux/string.h:300:9: note: in expansion of macro '__underlying_strncpy'
  300 |  return __underlying_strncpy(p, q, size);
      |         ^~~~~~~~~~~~~~~~~~~~

This is not a bug because the 1-byte array is used as an odd way to express
a variable-length data field here. I tried to convert it to a
flexible-array member, but in the end could not figure out why the
sizeof(struct fc_fdmi_???) are used the way they are, and how to properly
convert those.

Work around this instead by abstracting the string copy in a slightly
higher-level function fc_ct_hdr_fill() helper that strscpy() and memset()
to achieve the same result as strncpy() but does not require a
zero-terminated input and does not get checked for the array overflow
because gcc (so far) does not understand the behavior of strscpy().

Link: https://lore.kernel.org/r/20201026160705.3706396-2-arnd@kernel.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>