develooper Front page | perl.perl5.porters | Postings from April 2008

Re: bug or not? constants warn only once

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
April 25, 2008 16:51
Subject:
Re: bug or not? constants warn only once
Message ID:
20080425235121.GZ9606@klangraum.plasmasturm.org
* Nicholas Clark <nick@ccl4.org> [2008-04-25 12:20]:
> Why it surprised me was because I was trying to write a
> regression test, and this code
> 
> for my $kapow (0..1) {
> 
>     ... # Lots of other code
> 
>     $SIG{__WARN__} = ...;
> 
>     func_under_test(..., "constant");
> 
>     ... # check the warnings
> 
> }
> 
> didn't do what I expected, because that constant string
> "constant" in the optree isn't constant. Well, it can't be
> written to, but it gets conversions cached on it.
> 
> I guess my expectation is that constants in the optree either
> are, or are not, not some state in the middle where I can't
> change them from pristine, but the internals can.

I agree that literals should be constants and that this is
therefore a bug. This already warns twice:

    Readonly my $foo = "bar";
    0 + $foo; 0 + $foo;

So Perl already supports the desired behaviour, and the fix
therefore probably consists simply of setting some existing flag
at an opportune moment during parsing.

However I very strongly disagree with the people suggesting that 

    $bar = $foo + 2;
    $baz = $foo + 10;

should warn twice. I don’t think getting repeat warnings about
the same ultimate bug site has any value at all; in the above
example, there is one place in the code that would cause both
warnings. So either there is a problem in that one place and you
fix it, or there isn’t. What difference does it make whether the
same bug causes one or two or five or seventeen warnings?

The caching of conversions for literals is a bug not because it
suppresses subsequent warnings, but because literals are supposed
to be immutable. F.ex., mutable literals mean that bitwise op
expressions *with literals* can change their behaviour over the
course of a program – which is inarguably broken.

And if my ignorant surmise is correct, the fix, which would be
good defensive programming in any case, will be nearly free. In
contradistinciton, ensuring mutiple warnings seems to me like it
will require invasive changes: extra state for each variable will
need to be tracked in several places and checked in many others.

Perl has gotten a lot slower over time; let’s not add more bloat
if there isn’t good, or indeed any, reason for it.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About