Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

A Bug in the Documentation or in Perl?

by tlhf (Scribe)
on Aug 20, 2002 at 10:17 UTC ( #191426=note: print w/replies, xml ) Need Help??


in reply to [substr] anomaly or mine?

I've had code which uses substr($foo, n, n) = ''; as an rvalue. And I'm sure others have had code which used this too. If this usage is considered a bug and Perl was resultingly changed, then this code will be broken. And this code wasn't written on a bug - it was written on undefined behaviour. As such, then any change to the perl implementation should be considered a core language change.

With Perl 5 coming towards the latter half it's usage, is it sensible to be making core language changes? Surly it would just make more sense to define this behaviour - and change the documentation to reflect this difference.

tlhf
Just wanting to be able to upgrade Perl5 without fear of code breakage.

Replies are listed 'Best First'.
Re: A Bug in the Documentation or in Perl?
by Aristotle (Chancellor) on Aug 20, 2002 at 12:42 UTC

    See, undefined behaviour is just that.. if you rely on it, you are submitting to surprises. Of course, your stance is a legit one, and I do think that cases like yours have to be considered; old code should not be broken lightheartedly, even if it was written with dirty practices. But I do not believe that this argument can outweigh significant reasons that favour a change.

    I'm not saying that substr should be changed, rather than the current behaviour just becoming defined and documented. Whether there are any strong arguments in favour of a change in this specific instance is yet to be seen.

    I do however feel that reliance on poorly documented or defined behaviour or even on outright bugs is too common a bad habit and anything that will teach people to refrain from it can only be a good thing in the long term.

    After all, noone is forcing you to upgrade - Perl4, 5.0005_003 etc all still run fine. Old codebase does not have to be fixed right this instant.

    I realize this is somewhat of an ivory tower opinion and that things in the realworld don't quite always work the way I would like them to. However, unless you begin somewhere and sometime, that's never going to change. And in Germany they say (roughly), a terrifying end is better than neverending terror.

    In the end, I guess, it comes down to trying to find the best compromise. Legacy code should not hinder progress - but of course progress at all cost is no better either. Anyway, I think I'll quit this longwinded, meandering tangential post here before it goes much further.

    ____________
    Makeshifts last the longest.
      In a quick response, and some clarification:

      Yes, I agree that using undefined behaviour is bad style. That's an extremely valid point. I try at all costs to avoid such practices nowadays. But on the flipside, in Perl many things are undefined. Abigail-II has pointed out in the past that even $i = $i++; has undefined outcome, although all would agree that $i should not increment. The full debate started innocently here shows that there are many undefined parts to the very simplist of code. Yet most wouldn't complain such code's use.

      And I definitely agree that this should be cleared up. The point I was (poorly) trying to get at that this should not be fixed now. We're going to break pretty much the entire of Perl5 when Perl6 is released. We could sort out substr's odd behaviour then, and no harm will come of it.

      If this glitch was brought to attention a few years ago then I would have fully advocated a bug fix. But with it so late in the day now for Perl5, I geniunely believe the advantages of fixing this problem will be greatly outweighed by the problems it will cause. Perl5 is considered warty - and Perl6 is a fixup of those warts (with a few new groovy features added, naturally). I think it would make much more sense to just define this as it for Perl5 is in perldoc -f substr, and clean it in Perl6.

      tlhf
      Update: Slight typo; final $i was originally $i++;

Re: A Bug in the Documentation or in Perl?
by bart (Canon) on Aug 20, 2002 at 15:41 UTC
    I've had code which uses substr($foo, n, n) = ''; as an rvalue. And I'm sure others have had code which used this too. If this usage is considered a bug and Perl was resultingly changed, then this code will be broken.

    Eh? Are you serious? Then, please tell, what is this snippet supposed to do? Shouldn't you have used the 4-argument substr() instead?

    IMO, the value of an assignment is, commonly, what is assigned. This behaviour deviates from that generic rule in a very bizarre way: it does not return the new value, nor the old one. It just looks totally unreliable to me.

    And this code wasn't written on a bug - it was written on undefined behaviour. As such, then any change to the perl implementation should be considered a core language change.

    No way Jos. A change in previously undefined behaviour is called an improvement on the specification. You should never ever depend on undefined — or unspecified, behaviour. It is the prerogative of the Perl Porters to change that behaviour without any good reason.

    And changing the behaviour so that in some way it would start to make sense, either in line with the rest in the language and returning the newly assigned value, or returning the replaced value, which would be inconsistent with the rest but which might be very handy; well: these make sense. To me, anyway.

    I don't think your idiom is used that much.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2021-09-24 00:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?