Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: ref to read-only alias ... why? (notabug)

by dk (Chaplain)
on Jan 06, 2012 at 15:48 UTC ( #946617=note: print w/ replies, xml ) Need Help??


in reply to Re: ref to read-only alias ... why? (notabug)
in thread ref to read-only alias ... why?

I want it documented, and consistent. I agree that the for() case can be seen as stretched ( I like my for(1) to make an alias to $_ so I can do all magic with it inside the for block, but that's another story).

But anyway, what would you say about this then? Is this a bug or not?

sub x { my $ref = \ $_[0]; $$ref ++; } x(1);
I'd say that even if this behavior will be decided on as not a bug, then it has to be documented, at the very least.


Comment on Re^2: ref to read-only alias ... why? (notabug)
Download Code
Replies are listed 'Best First'.
Re^3: ref to read-only alias ... why? (notabug)
by tye (Cardinal) on Jan 06, 2012 at 16:28 UTC

    I'd document it pretty much as I already described it. Passing a read-only value or a literal constant to something that makes aliases (for, a sub) may decide to make an alias to the read-only value or may decide to make a copy of it. The decision might even be different in those two case (a literal constant vs. some other read-only scalar). The choice is a matter of optimization and subtle edge cases and Perl code should not depend on either specific behavior. Both behaviors have existed in many different versions of Perl.

    No, I don't consider it a bug that some versions of Perl don't die in the face of:

    sub add1 { return ++$_[0]; } my $two= add1(1);

    Despite the use of "++" over "1+" there being questionable. It does have the interesting and perhaps useful side effect of allowing: add1($count). Yes, it is a contrived example. As is yours.

    I don't find it hard to imagine cases where either result would be preferred. I do find it hard to imagine cases where either result is a serious problem that I wouldn't just address with a better interface for the subroutine.

    - tye        

      Thanks for commenting. Here's a case with a serious problem: a person writes code that doesn't fail, which then gets executed on another installation, and fails. I'd say it's bad enough. I believe I'd file a bug after all (unless you have reasons for me not to).

        Wow. To have code that runs fine for the author and then fails somewhere else constitutes a "serious problem" to you? Cushy world you must've lived in before. Ever looked at "cpan testers" reports? *shrug*

        I wouldn't file a bug. I'd rather just add an eval to the code (actually, I'd probably make a less fragile interface to the sub, as I said).

        - tye        

Re^3: ref to read-only alias ... why? (not consistent)
by LanX (Canon) on Jan 06, 2012 at 17:35 UTC
    Your right it's not consistent.

    But IMHO consistency will most likely break legacy code.

    I think that there should at least be a warning.

    Since it's not always clear if a variable is an alias, this can cause very hard to detect errors in subs which are meant to modify call-by-reference parameters. (not to be confused with Perl references)

    Did you check if there are already older bug-reports regarding this?

    Cheers Rolf

    UPDATE:

    DB<108> sub inc_a { $_[0]++; return } DB<109> $x=1; inc_a($x); print $x 2 DB<110> inc_a(1) Modification of a read-only value attempted at (eval 13)[/usr/share/pe +rl/5.10/perl5db.pl:638] line 2.

    but

    DB<111> sub inc_b { my $r=\ $_[0]; $$r++; return } DB<112> $x=1; inc_b($x); print $x 2 DB<113> inc_b(1) DB<114>

    When passing an aliasing variable instead of 1 it's the same problem. With inc_b non-aliasing vars will increment, but aliases will silently fail to increment.

      Your right it's not consistent. But IMHO consistency will most likely break legacy code.

      I think you're saying that because you envision it being consistently broken (always dying) instead of it being consistently fixed (never dying).

      There are two ways of fixing it:

      • Have literal constants always return new values. That's inefficient.
      • Have literal constants return copy-on-write values. There's currently no such mechanism, and that's a lot of work to implement.

      Check out this bug that would also be fixed by either of the above two fixes:

      for (1..2) { for (1..3) { print $_++; } # 123 234 print "\n"; }
      Heh, it's a 8-year old (!!!!) bug: https://rt.perl.org/rt3/Public/Bug/Display.html?id=21979 . With resolution that it's indeed a bug ... well, that situation doesn't seem good to me, when noone wants to touch a bug in 8 years. I wonder why.
        Thats what I expected.

        > I wonder why.

        IMHO legacy code would break if you die here.

        But a warning would be great.

        Cheers Rolf

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://946617]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (12)
As of 2015-07-08 05:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (94 votes), past polls