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
Comments
From @atoomicDiscovered 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. # perl -MDevel::Peek -e 'Dump( \+1 )' perl -MDevel::Peek -e 'Dump( \-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) |
From @cpansproutOn Fri, 20 Apr 2018 04:03:55 -0700, atoomic@cpan.org wrote:
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 $$_ }' 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 |
The RT System itself - Status changed from 'new' to 'open' |
It seems like an inconsistency that would be nice to fix. what is the expense? |
@iabyn any opinion on this? |
Migrated from rt.perl.org#133128 (status was 'open')
Searchable as RT133128$
The text was updated successfully, but these errors were encountered: