From: Nick Ing-Simmons [mailto:[EMAIL PROTECTED]] > Paul Marquess <[EMAIL PROTECTED]> 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