Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
>> I just think it's a case of "crying wolf", especially when other >> people's CPAN modules start spewing this stuff out from perfectly >> reasonable code, filling up your web error logs with "uninitialized this >> and that". As a sysadmin, that pisses me off. :-( >Much of your problem has been solved through lexical warnings. That's very true. People who globally enable warnings in code that isn't their own get precisely what they've asked for. 'Twas for this that lexical warnings were invented--amongst other things. Don't write #!/usr/bin/perl -w when you mean use warnings; As these are *not* the same thing. --tom
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
>But man, that really seems like it's not fun. And all alternatives are
>bound to be longer than this:
> my($a, $b, $c, $d, $e, $f) = getpwnam($user) || 'anonymous';
>Which is all I wanted to do in the first place! :-{
I do not think that that code that you have written there does what
you think that that code there is doing there.
That code assigns the new lexical variable $a to be the uid of the
user whose name is in $user--or else, failing that due to a bogus
return value or in the case of "root" which is going to be "0" and
annoy you (are we sure that we truly want string "0" forever false?),
it becomes "anonymous",
The other new lexical variables listed there are then antiïnitialized,
which in this case, has little distinguishing effect, but modulo
the my(), it could.
There is also peculiar situation that you're normally expecting a
numeric return, but have defaulted to a non-numerically valid string.
I suspect that was meant to be something like getpwuid($uid).
--tom
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
On Wed, 13 Sep 2000 19:57:28 -0700, Nathan Wiger wrote: >Perl should stop nagging about this. Perl should be smart and not bother >you about uninitialized values in the following situations: > > - string concat > - string comparison Allow me to disagree. In my case, I mostly use variables in output (= used as strings), far less in numerical context, and these warnings tell me that there are some situations that I had overlooked in my script. Most of the time, ignoring these warnings would make me rely on incorrect results. -- Bart.
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
On Wed, Sep 13, 2000 at 11:20:46PM -0700, Nathan Wiger wrote: [snippity-snip] > I just think it's a case of "crying wolf", especially when other > people's CPAN modules start spewing this stuff out from perfectly > reasonable code, filling up your web error logs with "uninitialized this > and that". As a sysadmin, that pisses me off. :-( > > Perhaps I should post to p5p about splitting up uninitialized warnings > into numeric and string contexts. Then at least I could get rid of all > the annoying strings ones and keep the number ones around. But the > problem of other people's CPAN modules is still a biggie... Much of your problem has been solved through lexical warnings. If you don't want uninitialized warnings you say: no warnings 'uninitialized'; and it's assumed you know what you're doing. If a module wants the same, it can do the same, and the change is restricted to just that module; similarly, if you want warnings, and an external module doesn't, it shouldn't have them forced upon it. If a module spits out warnings at some later date from perfectly fine usage then it's a bug with the module that should be reported and fixed. Defaulting to not spitting out uninitialized warning errors, IMHO, is a bad idea. If a programmer is going to be lazy about checking then that programmer should explicitly disable the setting; if it has a default of being turned off most people will simply leave it off, which will make bugs that much harder to track down. I can see the counter-argument: "well, use warnings and use strict is optional, why not add one more pragma?". The fact that use warnings and use strict being optional bites newbies, as has been mentioned. There are various arguments for and against, and I don't really care which way it goes, so long as I get strict and warnings; I don't, however, want to have to keep adding pragmas because various people are annoyed by a given warning or error. I say if the programmer is asking for warnings, give him warnings; if he wants fewer warnings, he has to say so. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
Nathan Torkington wrote:
>
> Tee hee! The point of the warning is to tell you that you should be
> checking it and aren't. You're assuming the variable has a value,
> because you are treating it like a string. But the variable doesn't
> have a value. This is probably an error.
For me it's not, that's why it's so damn annoying! I'm so *Lazy*.
Ridiculously so. I do stuff like:
do_stuff() unless ($string eq $maybe_undef);
All the time. And you can get to this point easily by;
$maybe_undef = call_func_that_might_return_undef();
And putting stuff like this to catch it:
$maybe_undef = call_func_that_might_return_undef() || '';
Is just plain a PITA.
> Saying:
>
> my $middle = '';
The problem is there's no easy way to do this for a large list of
values:
my($a, $b, $c, $d, $e, $f) = ();
Doesn't work. This does:
my($a, $b, $c, $d, $e, $f) = ('','','','','','');
But man, that really seems like it's not fun. And all alternatives are
bound to be longer than this:
my($a, $b, $c, $d, $e, $f) = getpwnam($user) || 'anonymous';
Which is all I wanted to do in the first place! :-{
I just think it's a case of "crying wolf", especially when other
people's CPAN modules start spewing this stuff out from perfectly
reasonable code, filling up your web error logs with "uninitialized this
and that". As a sysadmin, that pisses me off. :-(
Perhaps I should post to p5p about splitting up uninitialized warnings
into numeric and string contexts. Then at least I could get rid of all
the annoying strings ones and keep the number ones around. But the
problem of other people's CPAN modules is still a biggie...
-Nate
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
Nathan Wiger writes: >print "Welcome back, $first $middle $last!\n"; > > My question: What good is this warning in most contexts, anyways? > Really. Honestly. If you cared about the value, you would already be > checking it, right? Probably with something like this: > >die "Fatal: Can't continue with \$var unset!" unless $var; Tee hee! The point of the warning is to tell you that you should be checking it and aren't. You're assuming the variable has a value, because you are treating it like a string. But the variable doesn't have a value. This is probably an error. Either you didn't give the variable a value (for example, because it's 9-5 you didn't call the "authorize user" subroutine that would have set the $username variable) or you called a function to get a value for the variable, but the function returned undef to indicate an error and you never checked for that. Both of these situations are almost always errors. Saying: my $middle = ''; if you want to allow for the situation where there isn't a middle initial given isn't that much of a hardship, especially when you consider all the things that might go wrong. I've never had an "uninitialized value" warning that wasn't my own damn fault. At least, not that I can remember. Nat
Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
Nathan Torkington wrote:
>
> Turning Perl into a nagging harpie means that the really important
> warnings will be ignored.
>
> This line of thinking brought to you by Mark-Jason's excellent talk
> on data typing.
I agree, and just read MJD's paper the other day (nice job, BTW), but
unfortunately there are a couple warnings that are really on the edge of
nagging already, specifically:
Use of uninitialized value in concatenation (.) at line 32
Brought to you by the lovely:
print "Welcome back, $first $middle $last!\n";
How neat. Who else hates this? It's enough to drive me batty, and smacks
of the useless typecasts needed to shut C up.
Thankfully, Perl 5.6 allows you to say:
no warnings 'uninitialized';
But unfortunately you then have to block this off:
{
no warnings 'uninitialized';
print "$some $stuff\n";
}
Or put it in your whole code up at the top, in which case you miss out
on potentially useful uninitialized variable warnings just to maintain
your sanity (or make your CPAN module look clean).
My question: What good is this warning in most contexts, anyways?
Really. Honestly. If you cared about the value, you would already be
checking it, right? Probably with something like this:
die "Fatal: Can't continue with \$var unset!" unless $var;
Perl should stop nagging about this. Perl should be smart and not bother
you about uninitialized values in the following situations:
- string concat
- string comparison
Warning me that in:
$z = $x + $y;
$z = --$x;
do_stuff() unless ($x < 5);
$x is uninitialized is probably a good idea, because of the nature of
numeric ops. But telling me:
$name = $NAME unless ($name eq $local_name);
$name is uninitialized in the string eq is a waste. These warnings just
annoy, since in order to take advantage of them you have to put explicit
catches in your code anyways, like:
$name = $NAME unless ($name eq $local_name);
die "Fatal: Couldn't determine name!" unless $name;
And notice this is at a completely different logical point than the
warning would harp at. That's my($.02), if anyone agrees I'll write an
RFC (but I suspect my legs are about to be cut off :).
-Nate
