Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
hv_undef_flags: eliminate spurious -Warray-bounds warning
Eliminates: In file included from perl.h:6205, from hv.c:35: hv.c: In function ‘Perl_hv_undef_flags’: hv.h:460:26: warning: array subscript [0, 9223372036854775807] is outside array bounds of ‘char[0]’ [-Warray-bounds] 460 | #define HEK_FLAGS(hek) (*((unsigned char *)(HEK_KEY(hek))+HEK_LEN(hek)+1)) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ embed.h:292:78: note: in definition of macro ‘hv_common’ 292 | mmon(a,b,c,d,e,f,g,h) Perl_hv_common(aTHX_ a,b,c,d,e,f,g,h) | ^ hv.h:474:34: note: in expansion of macro ‘HEK_FLAGS’ 474 | #define HEK_UTF8(hek) (HEK_FLAGS(hek) & HVhek_UTF8) | ^~~~~~~~~ hv.h:579:55: note: in expansion of macro ‘HEK_UTF8’ 579 | hv_common((hv), NULL, HEK_KEY(hek), HEK_LEN(hek), HEK_UTF8(hek), \ | ^~~~~~~~ hv.c:2268:19: note: in expansion of macro ‘hv_deletehek’ 2268 | (void)hv_deletehek(PL_stashcache, HvNAME_HEK(hv), G_DISCARD); | ^~~~~~~~~~~~ This does appear to be spurious, the gcc documentation claims not to check array bounds on trailing 1 element arrays for backward compatibility. This warning would be reasonable if the hek itself was allocated on the stack, part of an array of HEKs, or embedded in another struct, but HvNAME_HEK() returns a pointer to a HEK, for which gcc has no knowledge of the source. This warning only appears in debugging builds, but the only difference from non-debugging builds is the HEKfARG() within the DEBUG_o(), which is a simple cast to (void *), which I don't see having an effect on whether the compiler considers HEK itself as part of a structure, or of unknown origin. So I expect it's just a gcc bug, and there are know issues with this warning.
- Loading branch information