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

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]

Replies are listed 'Best First'.
Re^4: Reason for this discrepancy with scalar?
by syphilis (Archbishop) on Mar 14, 2024 at 12:37 UTC
    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]
Re^4: Reason for this discrepancy with scalar?
by LanX (Saint) on Mar 14, 2024 at 12:52 UTC
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom