the uninitialized variable that wasn't

[Alan Curry]

I accidentally wrote this:

my $v = 12345; # really some input, verified to be neither 0 nor undef
# a few lines later...
my $str = sprintf "%06x\n". $v;

The warning actually made it harder to find the bug because it told me
something that wasn't true.

$ perl -we 'my $v = 12345; my $str = sprintf "%06x\n". $v;'
Use of uninitialized value $v in sprintf at -e line 1.

Wondering where and how $v became undef, I threw in some
defined($v) or die;
statements, and none of them died, including the one immediately before the
sprintf line with the warning, but still the warning said that $v was
"uninitialized", which I know really means undef.

Do you see the typo? That's not a comma.

The warning message accused an innocent bystander of being undefined.

 

[John Bokma]

$ perl -we 'my $v = 12345; my $str = sprintf "%06x\n". $v;'
Use of uninitialized value $v in sprintf at -e line 1.

Additionally, if you make $v undef you get:

Use of uninitialized value $x in concatenation (.) or string at -e line 1.
Use of uninitialized value $x in printf at -e line 1.

perl, v5.10.0 built for x86_64-linux-gnu-thread-multi

John

 

[Andrew DeFaria]

body { font: Helvetica, Arial, sans-serif; } p { font: Helvetica, Arial, sans-serif; } ..standout { font-family: verdana, arial, sans-serif; font-size: 12px; color: #993333; line-height: 13px; font-weight: bold; margin-bottom: 10px; } ..code { border-top: 1px solid #ddd; border-left: 1px solid #ddd; border-right: 2px solid #000; border-bottom: 2px solid #000; padding: 10px; margin-top: 5px; margin-left: 5%; margin-right: 5%; background: #ffffea; color: black; font-family: courier; white-space: pre; -moz-border-radius: 10px; } ..terminal { border-top: 10px solid #03f; border-left: 1px solid #ddd; border-right: 2px solid grey; border-bottom: 2px solid grey; padding: 10px; margin-top: 5px; margin-left: 5%; margin-right: 5%; background: black; color: white; font-family: courier; white-space: pre; -moz-border-radius: 10px; } blockquote[type=cite] { padding: 0em .5em .5em .5em !important; border-right: 2px solid blue !important; border-left: 2px solid blue !important; } blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid maroon !important; border-left: 2px solid maroon !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid teal !important; border-left: 2px solid teal !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid purple !important; border-left: 2px solid purple !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid green !important; border-left: 2px solid green !important; } a:link { color: blue; } a:visited { color: darkblue; } a:hover { color: black; background-color: #ffffcc; text-decoration: underline; } a:active { color: red; } On 11/30/2009 07:59 PM, Alan Curry wrote: I accidentally wrote this:

my $v = 12345; # really some input, verified to be neither 0 nor undef
# a few lines later...
my $str = sprintf "%06x\n". $v;

The warning actually made it harder to find the bug because it told me something that wasn't true.

$ perl -we 'my $v = 12345; my $str = sprintf "%06x\n". $v;'
Use of uninitialized value $v in sprintf at -e line 1.

Wondering where and how $v became undef, I threw in some
defined($v) or die;
statements, and none of them died, including the one immediately before the
sprintf line with the warning, but still the warning said that $v was
"uninitialized", which I know really means undef.

Do you see the typo? That's not a comma.

The warning message accused an innocent bystander of being undefined.
Looks like a Perl bug if you ask me. The underlying problem is that you're missing the second parameter to sprintf (think sprintf ("%06x\n") . $v or sprintf "%06x\n". Indeed, remove the ". $v" and you'll get a similar error. But the bug is that Perl should not have identified $v as the variable that was undefined because that was not true.

 

[Alan Curry]

Quoth (e-mail address removed) (Alan Curry):

Please report this minimal testcase using perlbug.

perlbug seems to depend on mail infrastructure that considers me unwelcome.

207.171.7.76 does not like recipient.
Remote host said: 550 http://www.spamhaus.org/query/bl?ip=98.226.122.10
Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

How much am I getting paid to jump through these hoops?

 

[John Bokma]

(e-mail address removed) (Alan Curry) writes:

[email via perlbug hits spamhaus]

207.171.7.76 does not like recipient.
Remote host said: 550 http://www.spamhaus.org/query/bl?ip=98.226.122.10
Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

http://www.spamhaus.org/pbl/query/PBL191978 gives:

Outbound Email Policy of Comcast for this IP range:

Email sent by Comcast subscribers using a mail program such as Outlook
Express are required to send the email through Comcast. To insure your
mail program is properly configured, please visit
http://www.comcast.net/help/faq/index.jsp?faq=Email117481. If you are a
Comcast Commercial Services customer and need support, please contact
support_biz [at] cable dot comcast dot com

Note: I munged the email address.

My guess is that Comcast doesn't block smtp outgoing for their customers [1]
and hence Comcast makes it a piece of cake for malware to spam the rest
of the world via their network, hence why they are in the PBL.


John

[1] customers as in customers who don't run knowingly their own mailserver.

 

[Uri Guttman]

JB> (e-mail address removed) (Alan Curry) writes:
JB> [email via perlbug hits spamhaus]

207.171.7.76 does not like recipient.
Remote host said: 550 http://www.spamhaus.org/query/bl?ip=98.226.122.10
Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

JB> http://www.spamhaus.org/pbl/query/PBL191978 gives:

JB> Outbound Email Policy of Comcast for this IP range:

JB> Email sent by Comcast subscribers using a mail program such as Outlook
JB> Express are required to send the email through Comcast. To insure your
JB> mail program is properly configured, please visit
JB> http://www.comcast.net/help/faq/index.jsp?faq=Email117481. If you are a
JB> Comcast Commercial Services customer and need support, please contact
JB> support_biz [at] cable dot comcast dot com

i have had the issue with comcast in the past and verizon now. if you
send mail directly, your leased IP may be flagged as a spammer. i used
to have qmail selectively send mail directly or via the ISP's mail
server but it got too painful. so i always use the outbound server as a
relay and i never get mail flagged as spam.

uri

 

[Alan Curry]

Interestingly, this bug does not seem to exist in 5.8:

$ perl -we 'my $v = 12345; my $str = sprintf "%06x\n". $v;'Use of
uninitialized value in sprintf at -e line 1.

Well, 5.10 is the first version that attempts to tell you which part of the
expression was undefined. Earlier versions can't get it wrong because they
aren't trying to get it right.

 

[Peter J. Holzer]

Please report this minimal testcase using perlbug.

perlbug seems to depend on mail infrastructure that considers me
unwelcome.

207.171.7.76 does not like recipient.
Remote host said: 550 http://www.spamhaus.org/query/bl?ip=98.226.122.10
Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

What's "extremely verbose yet content-free" about:

| IP Address Lookup
|
| 98.226.122.10 is not listed in the SBL
|
| 98.226.122.10 is listed in the PBL, in the following records:
|
| * PBL191978 [link to relevant policy]
|
| 98.226.122.10 is not listed in the XBL

How much am I getting paid to jump through these hoops?

I am quite sure that Comcast has set up a smart host for its customers
to use.

hp

 

[Alan Curry]

Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

What's "extremely verbose yet content-free" about:

You got different results than me, apparently. I only got this garbage:

|$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
|ERROR: The requested URL could not be retrieved
|ERROR
|The requested URL could not be retrieved
|While trying to retrieve the URL:
|http://www.spamhaus.org/query/bl?ip=98.226.122.10
|The following error was encountered:
|Access Denied.
|Access control configuration prevents your request from
|being allowed at this time. Please contact your service provider if
|you feel this is incorrect.
|Your cache administrator is webmaster.
|Generated Tue, 01 Dec 2009 11:51:09 GMT by www.spamhaus.org (squid/2.7.STABLE4)

(And that's how verbose it is after stripping the HTML tags.) Notice how it
uses 68 words to give no reason at all. You can guess the reason, and I can
too.

Hint: I'm making a point about how perlbug's mail system is referring me to a
web site I can't read because it disapproves not only of the way I do mail
but also of the way I do http. I demonstrated this with GET, the libwww-perl
http client - see spamhaus hating perl tools, while simultaneously being the
gatekeeper that decides who's allowed to submit perl bug reports - to
maximize the hilarity (if you've accepted the fact that Internet mail has
been permanently crippled by the spam war) or tragedy (if you're still hoping
for a comeback).

And I did know all this before I posted the first message in this thread.
It's not that I didn't try to do a bug report through official channels, it's
that I tried and it was rejected. So I reframed it as a mildly amusing
anecdote and posted it for the enjoyment of all. Being asked to use perlbug,
after perlbug had already told me I'm a naughty boy and my bug reports are
unwanted, may have made me a little bit peeved.

I am quite sure that Comcast has set up a smart host for its customers
to use.

So your bid is 0.

 

[John Bokma]

Giving up on 207.171.7.76.

$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
[snip an extremely verbose yet content-free error message]

What's "extremely verbose yet content-free" about:

You got different results than me, apparently. I only got this garbage:

|$ GET 'http://www.spamhaus.org/query/bl?ip=98.226.122.10'
|ERROR: The requested URL could not be retrieved
|ERROR
|The requested URL could not be retrieved
|While trying to retrieve the URL:
|http://www.spamhaus.org/query/bl?ip=98.226.122.10
|The following error was encountered:
|Access Denied.
|Access control configuration prevents your request from
|being allowed at this time. Please contact your service provider if
|you feel this is incorrect.
|Your cache administrator is webmaster.
|Generated Tue, 01 Dec 2009 11:51:09 GMT by www.spamhaus.org (squid/2.7.STABLE4)

(And that's how verbose it is after stripping the HTML tags.) Notice
how it uses 68 words to give no reason at all. You can guess the
reason, and I can too.

This has nothing to do with perlbug.

Hint: I'm making a point about how perlbug's mail system is referring
me to a web site I can't read because it disapproves not only of the
way I do mail but also of the way I do http. I demonstrated this with
GET, the libwww-perl http client - see spamhaus hating perl tools,

A lot of other sites do exactly the same thing, because perl tools were
and are used to write simple DOS (or even DDOS) tools and crawlers:

GET http://www.google.com/search?q=perldebug
<html><head><meta http-equiv="content-type"
content="text/html;charset=utf-8">
<title>403 Forbidden</title>

(reformatted, and rest of HTML deleted).

Providing a different user agent:
GET -H'User-Agent: Mozilla/5.0' http://www.google.debugearch?q=perld
(This simple one works with Google, you might have to do more work with
other sites).

while simultaneously being the gatekeeper that decides who's allowed
to submit perl bug reports - to maximize the hilarity (if you've
accepted the fact that Internet mail has been permanently crippled by
the spam war) or tragedy (if you're still hoping for a comeback).

Both your assumptions are wrong. Your attempt to send email failed
because it can't be distinguished from how a piece of malware on your
computer would send it. And your fetching of a page failed because the
tool you use can't be distinguished from a scriptkiddie attempt at
(D)DOS/crawling. Know your tools instead of blaming them, and certainly
don't blame them on perlbug, it has nothing to do with it ;-)

And I did know all this before I posted the first message in this
thread. It's not that I didn't try to do a bug report through
official channels, it's that I tried and it was rejected.

Yup, rejected by how your ISP choses to run things, IMO. There is a
reason that they are on a list by policy.

So I reframed it as a mildly amusing anecdote and posted it for the
enjoyment of all. Being asked to use perlbug, after perlbug had
already told me I'm a naughty boy and my bug reports are unwanted, may
have made me a little bit peeved.

The amusing part is that you made two wrong assumptions and blame the
wrong party. Sounds now less smart, no?

So your bid is 0.

Mine is 0 as well. Learn how things work those days (they won't change
soon), or find an ISP that allows you to send mail directly because you
seem to know what you're doing ;-)

John

 

[Alan Curry]

This has nothing to do with perlbug.

It was the end of a chain of error messages I followed diligently after
trying to use perlbug. There may have been other paths through the maze that
wouldn't have led to the same dead-end, but I refuse to enter this game of
guessing what software someone out there doesn't want me to use. None of my
choices were in violation of the relevant protocols. (Perhaps one might think
of "User-Agent: Mozilla" as a mandatory part of HTTP, since failing to
provide it leads to all kinds of crappy behavior, making this a bug in LWP.)

Yup, rejected by how your ISP choses to run things, IMO. There is a
reason that they are on a list by policy.

That I'm on the Internet at all is probably a violation of some policy since
I'm not a Windoze user. None of Comcast's software configuration advice
would be applicable to me, if I could actually read it.

The amusing part is that you made two wrong assumptions and blame the
wrong party. Sounds now less smart, no?

I've been doing this mail over dynamic DNS for a while now and so far, perl
is the only thing I haven't been able to send bug reports to. And I really
don't have any idea where the relay would be if I wanted to use it. Which I
don't. I've been against the idea of the mandatory relaying policy since it
came to my attention with the introduction of MAPS DUL long ago. I know
exactly what's going on, I know why people have made the decisions they've
made, including the ones I disagree with, since I watched it all as it was
happening. The mail system is fragmented now. It was too good to last.

 

[John Bokma]

guessing what software someone out there doesn't want me to use. None of my
choices were in violation of the relevant protocols. (Perhaps one might think
of "User-Agent: Mozilla" as a mandatory part of HTTP, since failing to
provide it leads to all kinds of crappy behavior, making this a bug in
LWP.)

You're to easy to blame the wrong program/library.

LWP is a HTTP client and I think it's correct if it sets it own HTTP
header instead of pretending to be something it clearly isn't. Moreover,
assuming you use bash (but I am sure other shells have similar
abilities) it's a piece of cake to create an alias which sets the
User-Agent header for you if you insist on reading HTML in your terminal.


John

 

[Eric Pozharski]

Additionally, if you make $v undef you get:

Use of uninitialized value $x in concatenation (.) or string at -e line 1.
Use of uninitialized value $x in printf at -e line 1.

perl, v5.10.0 built for x86_64-linux-gnu-thread-multi

or

{1230:2} [0:0]% perl -wle 'my $v = 15; my $str = sprintf "%06x\n" . $v;'
Use of uninitialized value $v in sprintf at -e line 1.
{1934:3} [0:0]% perl -wle 'my $v = 15; my $str = sprintf "%06x\n" , $v;'
{1939:4} [0:0]% perl -wle 'my $v = 15; my $str = sprintf "%06x\n" . $v , undef'
Use of uninitialized value in sprintf at -e line 1.

when copy-paste sux.

 

[RedGrittyBrick]

How much am I getting paid to jump through these hoops?

How much are you paying for your Perl compiler, support & maintenance?