develooper Front page | perl.perl5.changes | Postings from November 2022

[Perl/perl5] 2e4090: only fully calculate the stash (effective) namewh...

From:
Tony Cook via perl5-changes
Date:
November 18, 2022 23:13
Subject:
[Perl/perl5] 2e4090: only fully calculate the stash (effective) namewh...
Message ID:
Perl/perl5/push/refs/heads/blead/a33534-5b3c3c@github.com
  Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: 2e4090b82403991910f1fe64866048b62ccf5402
      https://github.com/Perl/perl5/commit/2e4090b82403991910f1fe64866048b62ccf5402
  Author: Tony Cook <tony@develop-help.com>
  Date:   2022-11-18 (Fri, 18 Nov 2022)

  Changed paths:
    M ext/XS-APItest/APItest.xs
    M gv.c
    M hv.c
    M hv.h
    M mg.c
    M mro_core.c
    M pp.c
    M pp_sys.c
    M scope.c
    M sv.c
    M util.c

  Log Message:
  -----------
  only fully calculate the stash (effective) name where needed

gcc 12 was complaining that evaluating (somehekptr)->hek_key
was always true in many places where HvNAME() or HvENAME() was
being called in boolean context.

Add new macros to check whether the names should be available and
use those instead.


  Commit: 970609e17c79578d2051de18f156f48701755715
      https://github.com/Perl/perl5/commit/970609e17c79578d2051de18f156f48701755715
  Author: Tony Cook <tony@develop-help.com>
  Date:   2022-11-18 (Fri, 18 Nov 2022)

  Changed paths:
    M hv.c
    M mro_core.c

  Log Message:
  -----------
  change HvENAME_HEK() to HvENAME_HEK_NN() where NULLs would crash anyway

gcc 12 was producing a confusing message complaining that
references to with hek_key[] were beyond the end of the array,
even though a properly HEK has bytes beyond the first we declare.

From experimentation I theorize the confusing message was produced
because HvENAME_HEK() can return a NULL pointer, and the array
pointed to by any NULL pointer is zero length, producing the
array bounds warning we were seeing.

Fixed by changing each hv_(fetch|delete)hek() call to use the
HvENAME_HEK_NN() macro variant, which doesn't include an explicit
NULL return value.

mro_method_changed_in() was a bit special, it evaluated the
hv_fetchhek() before the check for an anonymous stash, so I reordered
the code to take advantage of C99, checking the assertions before we
dereference the stash pointer, checking we have a name before trying
to look it up.


  Commit: 293512d5065deaf2e25e3854930ac526abf2ab60
      https://github.com/Perl/perl5/commit/293512d5065deaf2e25e3854930ac526abf2ab60
  Author: Tony Cook <tony@develop-help.com>
  Date:   2022-11-18 (Fri, 18 Nov 2022)

  Changed paths:
    M dump.c

  Log Message:
  -----------
  GvNAME() always returns a true value

gcc 12 was complaining that GvNAME() always returns a true value,
and that's also true.

Omit such uses in conditions.


  Commit: 5b3c3ccf1ae1689f1ece0eee6bca3b181514980f
      https://github.com/Perl/perl5/commit/5b3c3ccf1ae1689f1ece0eee6bca3b181514980f
  Author: Tony Cook <tony@develop-help.com>
  Date:   2022-11-18 (Fri, 18 Nov 2022)

  Changed paths:
    M dist/Devel-PPPort/module3.c

  Log Message:
  -----------
  Devel::PPPort/module3: eliminate the always true warning for the return

In this case we're testing that the result is always true, and it
happens the compiler realizes that the return value is always true,
even in isolation.

Returning the variable that we've already set to point to
PL_bufptr eliminates the warning.

The compiler is still smart enough to eliminate the comparison
on optimized builds.  Some linter may still complain about it.


Compare: https://github.com/Perl/perl5/compare/a33534361e54...5b3c3ccf1ae1



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About