in reply to Re: Reason for this discrepancy with scalar?
in thread Reason for this discrepancy with scalar?

This doesn't happen in 5.26.1 (I haven't tested any other old versions), where the our and my behave the same way.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Replies are listed 'Best First'.
Re^3: Reason for this discrepancy with scalar?
by choroba (Cardinal) on Mar 14, 2024 at 11:14 UTC
    After an hour of bisecting, I have the commit that changed the behaviour:

    https://github.com/Perl/perl5/commit/7be75ccf16313d987eb5a6e9ff6aec9fea4ef3d4

    optimise @array in boolean context
    It's quicker to return (and to test for) &PL_sv_zero or &PL_sv_yes, than setting a targ to an integer value or, in the vase of padav, creating a mortal sv and setting it to an integer value.
    In fact for padav, even in the scalar but non-boolean case, return &PL_sv_zero if the value is zero rather than creating and setting a mortal.

    Update: Compare to

    perl -MDevel::Peek -e 'Dump(!!0)'
SV = PVNV(0x1838140) at 0x18363f8
  REFCNT = 2147483647
  FLAGS = (IOK,NOK,POK,IsCOW,READONLY,PROTECT,pIOK,pNOK,pPOK)
  IV = 0
  NV = 0
  PV = 0x5e6583 "" [BOOL PL_No]
  CUR = 0
  LEN = 0

    [download]

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]
      I think this could be related to https://github.com/Perl/perl5/issues/19378.

      As of a couple years ago I stopped checking for equivalence to &PL_sv_yes in my XS files.
      Instead I now use SvTRUE_nomg_NN(sv) (and !SvTRUE_nomg_NN(sv) for FALSE).

      Nice work choroba.
      I think you've earned the right to file the bug report - or the PR, if you prefer ;-)

      Cheers,
      Rob
[reply]
[d/l]
[select]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom