Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normal mechanisms to create a constant do not work on undef #14077

Closed
p5pRT opened this issue Sep 8, 2014 · 8 comments
Closed

Normal mechanisms to create a constant do not work on undef #14077

p5pRT opened this issue Sep 8, 2014 · 8 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 8, 2014

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

Searchable as RT122728$

@p5pRT
Copy link
Author

p5pRT commented Sep 8, 2014

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
Copy link
Author

p5pRT commented Sep 8, 2014

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
Copy link
Author

p5pRT commented Sep 8, 2014

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

@p5pRT
Copy link
Author

p5pRT commented Sep 8, 2014

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
Copy link
Author

p5pRT commented Sep 8, 2014

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
Copy link
Author

p5pRT commented Sep 8, 2014

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
Copy link
Author

p5pRT commented Sep 9, 2014

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 p5pRT closed this as completed Sep 9, 2014
@p5pRT
Copy link
Author

p5pRT commented Sep 9, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant