scsi: libfc: Work around -Warray-bounds warning
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>
Showing
Please register or sign in to comment