From: Nick Ing-Simmons [mailto:nick(_dot_)ing-simmons(_at_)elixent(_dot_)com]
Paul Marquess <Paul(_dot_)Marquess(_at_)ntlworld(_dot_)com> writes:
Good catch Nick.
Instead of completely backing out the "defined $str or return" change, if
you change it to
unless (defined $str) {
warnif('uninitialized', 'Use of Uninitialized value in
encode_utf8');
return;
}
that gives us the same warning behaviour as print/tr/etc, but more
importantly it also gives users of the module the ability to silence the
uninitalized warning in the same way they do with print/tr, thus:
use warnings;
...
{
no warnings 'uninitialized';
Encode::encode_utf8($x);
}
But surely the warning we get now is (as a core warning) already so
controlled ?
The warning can be controlled if you place a "no warnings" in the scope where
the warning is generated. In the case above, that is *inside* the encode_utf8
function.
The setting of the warnings pragma in the block that calls encode_utf8 function
doesn't leak into the Encode function.
That's where warnings::warnif comes in. It checks to see if the warning is
enabled in the calling module. This allows module authors to give users of
their module the control over what warnings are generated.
Without adding the warnif calls to the code, the only way you can silence the
warning is
{
local $^W = 0 ;
Encode::encode_utf8($x);
}
and that only works if the function being called isn't itself under the control
of the warnings pragma. So for example
sub xxx
{
use warnings ;
my $a =~ tr/A/a/;
}
{
local $^W = 0 ;
xxx();
}
still generates the "Use of uninitialized value" warning.
I see that Encode does make use of the warnings pragma in places, so I'm not
sure if the "local $^W = 0" trick can be used with it.
And can we not enhance the message generator to fish the name out
of somewhere so that is says "Use of undefined in subroutine encode_utf8"
rather than just "subroutine entry" ?
That would be worth doing regardless.
Paul
