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

yyparse do not preserve ReadOnly flag for negative numbers pass as reference #16514

Open
p5pRT opened this issue Apr 20, 2018 · 6 comments
Open

yyparse do not preserve ReadOnly flag for negative numbers pass as reference #16514

p5pRT opened this issue Apr 20, 2018 · 6 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Apr 20, 2018

Migrated from rt.perl.org#133128 (status was 'open')

Searchable as RT133128$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @atoomic

Discovered this difference in behavior while working with Garu on Data​::Printer

A reference to a positive number has the ReadOnly flag set, whereas if that number is negative it's lost during the parsing process.
Note that "~1, -1, - -1, ... all behave in the same where RO is lost"
"+1, 1" on the other side are treated differently by yyparse

# perl -MDevel​::Peek -e 'Dump( \+1 )'
SV = IV(0x7f9f8a815310) at 0x7f9f8a815320
  REFCNT = 1
  FLAGS = (PADTMP,ROK,READONLY,PROTECT)
  RV = 0x7f9f8a8153e0
  SV = IV(0x7f9f8a8153d0) at 0x7f9f8a8153e0
  REFCNT = 1
  FLAGS = (IOK,READONLY,PROTECT,pIOK)
  IV = 1

perl -MDevel​::Peek -e 'Dump( \-1 )'
SV = IV(0x7f9d2e003480) at 0x7f9d2e003490
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0x7f9d2e003280
  SV = IV(0x7f9d2e003270) at 0x7f9d2e003280
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = -1

This is probably not a big deal but this difference would, for example, make that simple code attached to the ticket behaves differently.

I've tracked the difference in a gdb session and notice that yyparse was returning earlier for the positive number

331 if (yyn == YYPACT_NINF)
332 goto yydefault;

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @atoomic

test.pl

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

From @cpansprout

On Fri, 20 Apr 2018 04​:03​:55 -0700, atoomic@​cpan.org wrote​:

Discovered this difference in behavior while working with Garu on
Data​::Printer

A reference to a positive number has the ReadOnly flag set, whereas if
that number is negative it's lost during the parsing process.
Note that "~1, -1, - -1, ... all behave in the same where RO is lost"
"+1, 1" on the other side are treated differently by yyparse

# perl -MDevel​::Peek -e 'Dump( \+1 )'
SV = IV(0x7f9f8a815310) at 0x7f9f8a815320
REFCNT = 1
FLAGS = (PADTMP,ROK,READONLY,PROTECT)
RV = 0x7f9f8a8153e0
SV = IV(0x7f9f8a8153d0) at 0x7f9f8a8153e0
REFCNT = 1
FLAGS = (IOK,READONLY,PROTECT,pIOK)
IV = 1

perl -MDevel​::Peek -e 'Dump( \-1 )'
SV = IV(0x7f9d2e003480) at 0x7f9d2e003490
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x7f9d2e003280
SV = IV(0x7f9d2e003270) at 0x7f9d2e003280
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = -1

This is probably not a big deal but this difference would, for
example, make that simple code attached to the ticket behaves
differently.

I've tracked the difference in a gdb session and notice that yyparse
was returning earlier for the positive number

331 if (yyn == YYPACT_NINF)
332 goto yydefault;

This discrepancy was introduced in perl 5.20, by yours truly. The point was that constant folding is supposed to be an optimisation, and should not change a mutable return value into an immutable one.

One real problem that came up was that adding new instances of constant folding (new optimisations) actually broke things​:

$ perl5.14.4 -le 'for(\("a" x 10)) { $$_++; print $$_ }'
aaaaaaaaab
$ perl5.18.3 -le 'for(\("a" x 10)) { $$_++; print $$_ }'
Modification of a read-only value attempted at -e line 1.

I changed it so that constant folding always yields a mutable value. So now "foo" is read-only, but "foo"."bar" is mutable. (This is done using the SvPADTMP flag, which causes the value to be copied in any lvalue context.)

At the time, I never even thought about negated literal numbers; it never occurred to me that some might expect -3 to be treated effectively as a term, which is not an unreasonable expectation. Of course it is an operator followed by a term, and it is constant folding that turns it into a single term.

Is it worth making negation act differently from other folded operators? I think not. What do others think?

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 20, 2018

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

@toddr
Copy link
Member

@toddr toddr commented Oct 19, 2019

It seems like an inconsistency that would be nice to fix. what is the expense?

@atoomic
Copy link
Member

@atoomic atoomic commented Oct 19, 2019

@iabyn any opinion on this?

@xenu xenu removed the Severity Low label Dec 29, 2021
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

4 participants