Re: lc() with undefined arg

Also sprach Anno Siegel:

> Tassilo v. Parseval <tassilo.von.parseval@xxxxxxxxxxxxxx> wrote in comp.lang.perl.misc:
>> Also sprach ced@xxxxxxxxxxxxxxxxxxxxx:
>>
>> > Tassilo v. Parseval wrote:
>
> [...]
>
>> But I don't see how the functions mentioned in this thread fall into
>> this category. Meanwhile, I found one other builtin that wont warn on
>> undef: 'reverse' in scalar context.
>>
>> What is worse about these cases is the fact that after applying any of
>> these functions, the value is no longer undef but the empty string. In a
>> context of a program these two values might have a very different
>> meaning and silently transforming one into the other is wrong.
>
> That's only a consequence of some functions stringifying their argument,
> the same goes for hash keys. I wouldn't worry about it, a programmer
> doesn't expect a function like lc to return its argument unchanged. I think
> it's just a missing "uninitialized" warning -- add that and reverse and
> lc fit right in.

Yes, I am not worried about the empty string that is produced but the
fact that it happens silently. When I get warnings about uninitialized
values it's almost always a bug in my programs. So that's a warning I
cannot do without.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
.

Relevant Pages

  • Re: Why arent warnings on by default?
    ... > Also sprach Anno Siegel: ... >> no reason not to use warnings. ... Or maybe it's a potential bug that could occur under ...
    (comp.lang.perl.misc)
  • Re: Why arent warnings on by default?
    ... > Also sprach Anno Siegel: ... >> If a module issues warnings the author didn't intend the user to see, ... but there the warning itself becomes the bug. ... That scope would rarely be the entire module, ...
    (comp.lang.perl.misc)