My first guess was that $key is undef. But I'll get back to that...

The respondant who said that either $SERVER{$key}{one} or $SERVER{$key}{two} is undef was wrong. The one who said that printing "0" instead of the empty string meant that neither of those is undef is correct.

But my first guess is also wrong because you didn't get the warning from the print statement. So my final guess is that one of the else or one of the elsifs associated with that if is really where the warning is coming from.

For some reason, Perl often (always?) reports errors in the else and elsifs as if they came from within the if. I used to think that this was due to an optimization trick but that trick was only done in Perl 4.

Doh! Forgot to login above. Should have noticed the lack of sig. The problem was really in the elsif below the if. You were right, tye. Thanks a lot! Now my program is running great with strict & -w with zero warnings.

-billyak

As for what the correct way to solve it is, that depends on the application itself. If it's critical that these variables do have some meaning, something like die "server key one not defined" unless defined ($SERVER{$key}{one}); will tell you when the first one's undefined. If it's ok, then there's a variety of things you can do, but you'll need to check for definedness in (I think) any case.

Since you get zeros instead of blanks, you don't have uninitialized values in the print. I suspect a typo in the if statement.

mannequin approach: Call someone over to look at the problem, but just as they get there look at the code again. You'll probably spot the error.

1 == 1 && 1 == 1
[download]

I couldn't reproduce the error from the code given. Can you supply a bit more? Here's what I tested with:

#!/usr/bin/perl

use strict;
use warnings;
use diagnostics;

my %SERVER;
my $key = 1;
$SERVER{$key}{one} = $SERVER{$key}{two} = 1;
print "$SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1\n";
if($SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1){
}
[download]

prints:1 == 1 && 1 == 1but no warning.

HTH,
Charles K. Clarkson

print "$SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1\n";
no warnings 'uninitialized';
if($SERVER{$key}{one} == 1 && $SERVER{$key}{two} == 1){
  ...
}
use warnings 'all'; # I think it's a nice warning, I never want it off
+ for very long... ymmv
[download]

I didn't want to use the weenie method and localize the warning variable to stop this warning; what is the correct way to fix this?

Mabey you aren't using a variable, but I think this isn't in the spirit of what the poster wants.

The 15 year old, freshman programmer,
Stephen Rawls

Maybe it is, maybe it isn't, but it is the best way to do it. The only other things you can do are add lots of tests or turn off all warnings. Lots of tests can be clunky, and no warnings at all means you have to keep the code locked in the basement where nobody can see it. ;)

But, most of the complaints about the old way of turning off warnings aren't relevant to the new pragma. It _is_ bad to be messing with localized vars to control the compiler or interpreter. It got the job done, but I'm sure happy for the warnings pragma and filehandles as objects... it lets me throw local out of my box altogether.
--
Snazzy tagline here

Please do not do this.... This is akin to turning up the radio so you don't hear the nasty sounds your engine is making. The warning is there because you are likely missing a condition that you did not think of, turning off warnings only removes the message not the problem it is warning you about.

warnings are a good thing. I'd never just turn them off to begin with. But saying that an experienced programmer is likely missing something because there is a warning is rather suspect. The argument works great for the general case, because at the level of a whole program there is a lot more room to miss something. But, if there is a reason not to turn off specific warnings for a short time, it isn't that there is still a "problem." For example, if you'll dealing with hashes, you'll get uninitialized errors in some types of things, but whether it's initialized might be besides the point. If it exists might really be what matters.

Adding extra code that isn't needed to get rid of the warning is at least as bad as turning off the warning where you know it isn't a problem, so judgement is required.

I think a good rule is, "if you fully understand why you're getting the warning, then it's your call if it should be on or off." If you don't know what the warning is, but just want it to shut up, then yeah, read the manual, fix the code, etc.
--
Snazzy tagline here