Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > A Spurious Warning

Reply
Thread Tools

A Spurious Warning

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-27-2011
Below is a Perl subroutine supposed to parse a CIDR IPv4 network
specification and return the numerical values of the first and last
addresses in this range (this code is (c) my employer and quoted here
for educational purposes):

sub parse_net_spec($)
{
my ($first, $mask, @octets, $prefix);

$_[0] =~ /^((?:\d{1,3}\.){0,3}\d{1,3})\/(\d\d?)$/ && do {
$prefix = $2;
die('prefix too large') unless $prefix < 33;

@octets = split(/\./, $1);
for (@octets) {
die('octet too large') unless $_ < 256;
$first = $first << 8 | $_;
}
$first <<= 8 * (4 - @octets);

$mask = (1 << (32 - $prefix)) - 1;
return ($first & ~$mask, $first | $mask);
};

die("'$_[0]' does not look like a CIDR network specification");
}

As far as I know, this function is correct in the sense that it should
reject any invalid input and produce the intended result for each
valid one (information to the contrary very much welcome). This will,
of course, given a suitably adjusted perl invocation, result in a

Use of uninitialized value $first in left bitshift (<<)

warning, despite the automatic conversion which is going to take place
here will result in the correct value (0).

What was the precise reason why this is supposed to be 'something that
should not be'?
 
Reply With Quote
 
 
 
 
Randal L. Schwartz
Guest
Posts: n/a
 
      09-27-2011
>>>>> "Rainer" == Rainer Weikusat <(E-Mail Removed)> writes:

Rainer> my ($first, $mask, @octets, $prefix);

....

Rainer> $first = $first << 8 | $_;

....

Rainer> As far as I know, this function is correct in the sense that it should
Rainer> reject any invalid input and produce the intended result for each
Rainer> valid one (information to the contrary very much welcome). This will,
Rainer> of course, given a suitably adjusted perl invocation, result in a

Rainer> Use of uninitialized value $first in left bitshift (<<)

You never initialize $first.

Just like it says.

This is why I really discourage:

my ($list, $of, $variables);

You should introduce each variable at a time when you have a meaningful
initial value:

my $first = 0;

and so on.

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<(E-Mail Removed)> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
 
Reply With Quote
 
 
 
 
Charlton Wilbur
Guest
Posts: n/a
 
      09-27-2011
>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

RW> This will, of course, given a suitably adjusted perl invocation,
RW> result in a

RW> Use of uninitialized value $first in left bitshift (<<)

RW> warning, despite the automatic conversion which is going to take
RW> place here will result in the correct value (0).

RW> What was the precise reason why this is supposed to be
RW> 'something that should not be'?

Generally, performing arithmetic on undefined values is a sign of an
error or an omission. The Perl compiler cannot infer your intent from
the code, and so errs on the side of caution by issuing a warning.

In this case, the automatic conversion is what you intend and what you
expect. If the warning bothers you, silence it with "no warnings
'uninitialized';" or don't "use warnings;" in the first place.

Charlton




--
Charlton Wilbur
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-27-2011
(E-Mail Removed) (Randal L. Schwartz) writes:
>>>>>> "Rainer" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> Rainer> my ($first, $mask, @octets, $prefix);
>
> ...
>
> Rainer> $first = $first << 8 | $_;
>
> ...
>
> Rainer> As far as I know, this function is correct in the sense that it should
> Rainer> reject any invalid input and produce the intended result for each
> Rainer> valid one (information to the contrary very much welcome). This will,
> Rainer> of course, given a suitably adjusted perl invocation, result in a
>
> Rainer> Use of uninitialized value $first in left bitshift (<<)
>
> You never initialize $first.
>
> Just like it says.


Well, yes. perl initializes $first to 'an undefined value' (which is
actually a well-defined value with a specific property) and the result
of converting this 'undefined null string', as the perldata(1) manpage
calls it, to a number is the number zero. Which happens to be the
numerical value needed at the 'place' of the calculation where it is
being used.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-27-2011
Charlton Wilbur <(E-Mail Removed)> writes:
>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> RW> This will, of course, given a suitably adjusted perl invocation,
> RW> result in a
>
> RW> Use of uninitialized value $first in left bitshift (<<)
>
> RW> warning, despite the automatic conversion which is going to take
> RW> place here will result in the correct value (0).
>
> RW> What was the precise reason why this is supposed to be
> RW> 'something that should not be'?
>
> Generally, performing arithmetic on undefined values is a sign of an
> error or an omission.


Given that this is a well-defined operation and has always been one,
this statement seems unjustifiable to me. Especially since a newly
created variable with no explicitly assigned other value will start
its 'arithmetic life' as zero and this is obviously useful whenever
some series of arithmetic operations involving said variable is
supposed to start with a value of zero.

As I wrote in a past posting: This is a feature I have always liked in
Perl because it means explicit initialization is not necessary when 'a
null value' of some suitable type is all that is needed (meaning,
something which is ether undefined, false, 0 or '', depending on what
use it is supposed to be put to).
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      09-27-2011
>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

RW> Charlton Wilbur <(E-Mail Removed)> writes:

>> Generally, performing arithmetic on undefined values is a sign of
>> an error or an omission.


RW> Given that this is a well-defined operation and has always been
RW> one, this statement seems unjustifiable to me.

The compiler cannot infer your intent. The compiler cannot distinguish
between a variable that you have left undefined because you are a
brilliant programmer who expects the undefined value to be converted to
0 in an arithmetic context, and a variable that you have left undefined
because you are a novice programmer who doesn't know any better.

Not making your intent clear to the compiler -- and to maintenance
programmers -- by explicitly initializing the variable to 0 or turning
off uninitialized value warnings *is* an error or an omission.

Charlton


--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
Mart van de Wege
Guest
Posts: n/a
 
      09-28-2011
Charlton Wilbur <(E-Mail Removed)> writes:

>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> RW> This will, of course, given a suitably adjusted perl invocation,
> RW> result in a
>
> RW> Use of uninitialized value $first in left bitshift (<<)
>
> RW> warning, despite the automatic conversion which is going to take
> RW> place here will result in the correct value (0).
>
> RW> What was the precise reason why this is supposed to be
> RW> 'something that should not be'?
>
> Generally, performing arithmetic on undefined values is a sign of an
> error or an omission. The Perl compiler cannot infer your intent from
> the code, and so errs on the side of caution by issuing a warning.
>

I applaud your patience, but let's be fair: Rainer has been riding his
hobby horse against 'uninitialized' warnings for months now.

By this time he is just trolling. Just killfile him.

Mart

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
 
Reply With Quote
 
Randal L. Schwartz
Guest
Posts: n/a
 
      09-28-2011
>>>>> "Rainer" == Rainer Weikusat <(E-Mail Removed)> writes:

Rainer> Given that this is a well-defined operation and has always been one,
Rainer> this statement seems unjustifiable to me.

You lost me there. define "well-defined" and "always has", and we might
have room for a conversation.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<(E-Mail Removed)> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      09-28-2011
>>>>> "MvdW" == Mart van de Wege <(E-Mail Removed)> writes:

MvdW> I applaud your patience, but let's be fair: Rainer has been
MvdW> riding his hobby horse against 'uninitialized' warnings for
MvdW> months now.

MvdW> By this time he is just trolling. Just killfile him.

I don't killfile - I use Gnus, which does an admirable job of noticing
what I care to read and skipping over posts I do not care to read. When
Gnus shows me a post by Rainer where he's engaged in his wingnuttery, I
respond with sanity. I figure if it helps at least one lurker to
understand that Rainer is a wingnut, it's worth the five minutes, and
it's a welcome brief distraction from what I'm actually supposed to be
working on.

Charlton



--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      09-28-2011
(E-Mail Removed) (Randal L. Schwartz) writes:
>>>>>> "Rainer" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> Rainer> Given that this is a well-defined operation and has always been one,
> Rainer> this statement seems unjustifiable to me.
>
> You lost me there. define "well-defined" and "always has", and we might
> have room for a conversation.


There are actually two varieties of null strings (sometimes referred
to as "empty" strings), a defined one and an undefined one.

[...]

strings that aren't numbers count as 0, just as they do in awk

A null string (no matter if defined or undefined) "isn't a number",
hence, its numerical value is 0. This implies that the value of each
arithmetic operation involving (defined or undefined) 'null strings'
is predictable based on the defined semantics of the operater being
used and possibly, the numerical value of the other operand. Using a
free translation from a German Wikipedia page on 'Wohldefiniertheit':

In einem weiteren Sinn wird Wohldefiniertheit auch auf andere Bereiche
ausgedehnt. Sie bezeichnet dann eine sinnvolle und widerspruchsfreie
Definition.

In English, this should roughly be: [The term] well-definedness is
also used in a more general sense to mean sensible, non-contradictory
definition.

This interpretation of non-numerical strings as 0 is sensible in the
sense that it is consistent with a preexisting convention and
doesn't contradict itself.

As for the 'always has': Please provide quote which show that the
documented behaviour of Perl was different from the behaviour
documented in the quote above. This would demonstrate that 'it has
always been this way' [for Perl5] isn't true.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Spurious 'low space' warning on XP mounted volume ChrisM Computer Support 2 09-04-2006 10:54 PM
spurious DMZ Barrett Bonden Cisco 1 02-01-2006 05:50 AM
Status query: Java 1.5 Linux spurious mouse clicked events. Ian A. Mason Java 0 02-24-2005 04:15 AM
Re: spurious wakeup Markus Elfring C++ 0 11-25-2004 11:34 AM
Spurious Access Mark St Laurent Cisco 6 10-01-2004 02:20 AM



Advertisments