Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: eff57c4d73898d2174f80490cb2efe2821f5ea46
      
https://github.com/Perl/perl5/commit/eff57c4d73898d2174f80490cb2efe2821f5ea46
  Author: Tony Cook <t...@develop-help.com>
  Date:   2024-04-15 (Mon, 15 Apr 2024)

  Changed paths:
    M hv.c

  Log Message:
  -----------
  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.


  Commit: 1edc2b4ee3077fc72d6364edfe0281ea10aab252
      
https://github.com/Perl/perl5/commit/1edc2b4ee3077fc72d6364edfe0281ea10aab252
  Author: Tony Cook <t...@develop-help.com>
  Date:   2024-04-15 (Mon, 15 Apr 2024)

  Changed paths:
    M locale.c

  Log Message:
  -----------
  toggle_locale_i: eliminate NULL for %s format warning

The C99 printf() family of functions do not permit a NULL
pointer for the %s format specifier.

In this case, there's a NULL check done immediately afterwards,
allowing the compiler to detect that locale_to_restore_to could
be NULL.

While PerlIO_printf() (via sv_vcatpvfn_flags()) does allow NULL,
it isn't permitted by the standard implementation, so gcc warns.

Ideally the compiler would provide customisation hooks for this
warning, but it doesn't, and since the -Wformat family of
warnings are useful, do the minimal change to prevent it in
this case.


Compare: https://github.com/Perl/perl5/compare/a7b106d5563e...1edc2b4ee307

To unsubscribe from these emails, change your notification settings at 
https://github.com/Perl/perl5/settings/notifications

Reply via email to