Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

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.

Replies are listed 'Best First'.
Re^3: ref to read-only alias ... why? (notabug)
by tye (Sage) 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 (Sage) 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


    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/] line 2.


    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: . 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?

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2022-08-17 01:04 GMT
Find Nodes?
    Voting Booth?

    No recent polls found