Normal mechanisms to create a constant do not work on undef

[p5pRT]

Migrated from rt.perl.org#122728 (status was 'resolved')

Searchable as RT122728$

[p5pRT]

From @demerphq

Both of these subs should be identified as constants by the perl internals,
however the first one fails to be marked as CONSTANT and therefore does not
alter the parse tree.

Bug affects at least perl 5.14, and is still present in bleadperl.

For some reason constant.pm is able to create constants which are undef.

Yves

$ perl -MDevel​::Peek -le'sub K1 () { undef } sub K2() { 0 } Dump(\&K1);
Dump(\&K2)'
SV = IV(0x9f6988) at 0x9f6998
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0xa15a98
  SV = PVCV(0xa13ac8) at 0xa15a98
  REFCNT = 2
  FLAGS = (POK,pPOK)
  PROTOTYPE = ""
  COMP_STASH = 0x9f6800 "main"
  START = 0xa20890 ===> 0
  ROOT = 0xa20a10
  GVGV​::GV = 0xa1f688 "main" :​: "K1"
  FILE = "-e"
  DEPTH = 0
  FLAGS = 0x0
  OUTSIDE_SEQ = 93
  PADLIST = 0xa1f700
  PADNAME = 0xa1f6b8(0xa20f30) PAD = 0x9f6a88(0xa1b730)
  OUTSIDE = 0x9f6bf0 (MAIN)
SV = IV(0x9f6988) at 0x9f6998
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0xa1f7f0
  SV = PVCV(0xa51a60) at 0xa1f7f0
  REFCNT = 2
  FLAGS = (POK,pPOK,CONST,ISXSUB)
  PROTOTYPE = ""
  COMP_STASH = 0x0
  XSUB = 0x7f5ae3af1d40
  XSUBANY = 0xa1f820 (CONST SV)
  SV = IV(0xa1f810) at 0xa1f820
  REFCNT = 1
  FLAGS = (IOK,READONLY,pIOK)
  IV = 0
  GVGV​::GV = 0xa23680 "main" :​: "K2"
  FILE = "-e"
  DEPTH = 0
  FLAGS = 0xc
  OUTSIDE_SEQ = 0
  PADLIST = 0x0
  OUTSIDE = 0x0 (null)

--
perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @cpansprout

On Sun Sep 07 23​:33​:08 2014, demerphq wrote​:

Both of these subs should be identified as constants by the perl internals,
however the first one fails to be marked as CONSTANT and therefore does not
alter the parse tree.

Optimising pp_undef to pp_const when it has no arguments is on my to-do list.

Bug affects at least perl 5.14, and is still present in bleadperl.

For some reason constant.pm is able to create constants which are undef.

This looks constant to me, or did you mean &PL_sv_undef?

$ perl -MDevel​::Peek -e 'use constant K1=>undef; Dump \&K1'
SV = IV(0x7f91f40070c8) at 0x7f91f40070d0
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0x7f91f402c348
  SV = PVCV(0x7f91f402dc20) at 0x7f91f402c348
  REFCNT = 2
  FLAGS = (POK,pPOK,CONST)
  PROTOTYPE = ""
  COMP_STASH = 0x7f91f4006f38 "main"
  XSUB = 0x10a8299fd
  XSUBANY = 0x7f91f40482d8 (CONST SV)
  SV = NULL(0x0) at 0x7f91f40482d8
  REFCNT = 1
  FLAGS = (PADMY,READONLY)
  GVGV​::GV = 0x7f91f404c338 "main" :​: "K1"
  FILE = "-e"
  DEPTH = 0
  FLAGS = 0xc00
  OUTSIDE_SEQ = 0
  PADLIST = 0x0
  OUTSIDE = 0x0 (null)

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @demerphq

On 8 September 2014 15​:32, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sun Sep 07 23​:33​:08 2014, demerphq wrote​:

Both of these subs should be identified as constants by the perl
internals,
however the first one fails to be marked as CONSTANT and therefore does
not
alter the parse tree.

Optimising pp_undef to pp_const when it has no arguments is on my to-do
list.

Bug affects at least perl 5.14, and is still present in bleadperl.

For some reason constant.pm is able to create constants which are undef.

This looks constant to me, or did you mean &PL_sv_undef?

$ perl -MDevel​::Peek -e 'use constant K1=>undef; Dump \&K1'

SV = IV(0x7f91f40070c8) at 0x7f91f40070d0

REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x7f91f402c348
SV = PVCV(0x7f91f402dc20) at 0x7f91f402c348
REFCNT = 2
FLAGS = (POK,pPOK,CONST)

No, I was observing the same point you are here, for some reason constant.pm
*is* able to create constants which are undef, /unlike/ the sub prototype
thingee.

Yves

[p5pRT]

From @cpansprout

On Mon Sep 08 09​:59​:48 2014, demerphq wrote​:

On 8 September 2014 15​:32, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sun Sep 07 23​:33​:08 2014, demerphq wrote​:

Both of these subs should be identified as constants by the perl
internals,
however the first one fails to be marked as CONSTANT and therefore does
not
alter the parse tree.

Optimising pp_undef to pp_const when it has no arguments is on my to-do
list.

Bug affects at least perl 5.14, and is still present in bleadperl.

For some reason constant.pm is able to create constants which are undef.

This looks constant to me, or did you mean &PL_sv_undef?

$ perl -MDevel​::Peek -e 'use constant K1=>undef; Dump \&K1'

SV = IV(0x7f91f40070c8) at 0x7f91f40070d0

REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x7f91f402c348
SV = PVCV(0x7f91f402dc20) at 0x7f91f402c348
REFCNT = 2
FLAGS = (POK,pPOK,CONST)

No, I was observing the same point you are here, for some reason constant.pm
*is* able to create constants which are undef, /unlike/ the sub prototype
thingee.

Sorry, I misread you. Maybe I should start wearing my glasses at the computer. :-)

Fixing this is trivial, but I would appreciate any response to the issue I raised in ticket #35129, since it is related.

--

Father Chrysostomos

[p5pRT]

From @demerphq

On 8 September 2014 21​:38, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Mon Sep 08 09​:59​:48 2014, demerphq wrote​:

On 8 September 2014 15​:32, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sun Sep 07 23​:33​:08 2014, demerphq wrote​:

Both of these subs should be identified as constants by the perl
internals,
however the first one fails to be marked as CONSTANT and therefore
does
not
alter the parse tree.

Optimising pp_undef to pp_const when it has no arguments is on my to-do
list.

Bug affects at least perl 5.14, and is still present in bleadperl.

For some reason constant.pm is able to create constants which are
undef.

This looks constant to me, or did you mean &PL_sv_undef?

$ perl -MDevel​::Peek -e 'use constant K1=>undef; Dump \&K1'

SV = IV(0x7f91f40070c8) at 0x7f91f40070d0

REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x7f91f402c348
SV = PVCV(0x7f91f402dc20) at 0x7f91f402c348
REFCNT = 2
FLAGS = (POK,pPOK,CONST)

No, I was observing the same point you are here, for some reason
constant.pm
*is* able to create constants which are undef, /unlike/ the sub prototype
thingee.

Sorry, I misread you. Maybe I should start wearing my glasses at the
computer. :-)

Its cool. I could have worded it better anyway.

Fixing this is trivial, but I would appreciate any response to the issue I
raised in ticket #35129, since it is related.

I responded to the ticket. In short, yes, im opinion you should go ahead
and "fix" the "*" prototype. From what I can tell the * prototype dies or
does clearly weirdass buggy shit when dealing with a bareword that is also
a subroutine, and I think we should just fix it one way or another.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @cpansprout

On Mon Sep 08 06​:32​:04 2014, sprout wrote​:

On Sun Sep 07 23​:33​:08 2014, demerphq wrote​:

Both of these subs should be identified as constants by the perl
internals,
however the first one fails to be marked as CONSTANT and therefore
does not
alter the parse tree.

Optimising pp_undef to pp_const when it has no arguments is on my to-
do list.

(I meant OP_UNDEF and OP_CONST.)

Except that is not the best approach. A const op needs a slot in the pad under threads, so that would increase memory usage. pp_undef already has an early return for no arguments, so using pp_const instead would probably not speed things up.

So I used a different approach. I taught op_const_sv about OP_UNDEF with !op_private in commit 1542cb4.

More general constant folding for undef has yet to be done, but this ticket is resolved. (Actually, would folding undef make much difference? Most people have warnings on, so uninit warnings would prevent folding anyway.)

--

Father Chrysostomos

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'