Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > lc() with undefined arg

Reply
Thread Tools

lc() with undefined arg

 
 
Len@Weisberg.com
Guest
Posts: n/a
 
      08-11-2005
I expected this to give a warning for "uninitialized value" :
perl -w -e 'my $abc; print "\L$abc";'
But it doesn't!

Why is this different from:
perl -w -e 'my $abc; print "$abc";'
which DOES give the expected warning ?

Is it documented that lc() doesn't mind an undefined argument ?
Or is something else going on?

I'm interested in this because the following would be kind of neat
if I could trust that it would work cleanly into the future,
even if Flag was missing from the hash:
if ("\L$hash->{'Flag'}" eq 'yes') {...}

If I don't understand why it works, I'll continue to use the rather
messier:
if (lc ($hash->{'Flag'} || '') eq 'yes') {...}

(BTW, about omitting the quotes, as in $hash->{Flag} :
is this considered sound practice, or is it just lazy ?)

Cheers,

-Len

 
Reply With Quote
 
 
 
 
Paul Lalli
Guest
Posts: n/a
 
      08-11-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> I expected this to give a warning for "uninitialized value" :
> perl -w -e 'my $abc; print "\L$abc";'
> But it doesn't!
>
> Why is this different from:
> perl -w -e 'my $abc; print "$abc";'
> which DOES give the expected warning ?
>
> Is it documented that lc() doesn't mind an undefined argument ?


Not that I can see anywhere, but that certainly does seem to be the
case:

perl -MData:umper -wle '$bar = lc($foo); print Dumper(\$foo, \$bar);'
$VAR1 = \undef;
$VAR2 = \'';

> if (lc ($hash->{'Flag'} || '') eq 'yes') {...}
>
> (BTW, about omitting the quotes, as in $hash->{Flag} :
> is this considered sound practice, or is it just lazy ?)


It could come back to bite you one day if: 1) a future release of Perl
suddenly introduces a Flag() function; 2) your code is modified to
include a Flag() subroutine; 3) your code is modified to import a
module which exports a Flag() subroutine; 4) your code is modified to
include a constant named Flag. If you're worried about one or more of
those, much safer to use the quotes.

Paul Lalli

Paul Lalli

 
Reply With Quote
 
 
 
 
Len@Weisberg.com
Guest
Posts: n/a
 
      08-11-2005
>> Is it documented that lc() doesn't mind an undefined argument ?
>
>Not that I can see anywhere, but that certainly does seem to be the
>case:


Thanks, Paul, for the quick reply. If no one can assure me that
this is documented behavior, I won't depend on it.

Should this failure to warn be reported as a bug?
If so, what is the best way to do that?

Cheers,
-Len

 
Reply With Quote
 
Paul Lalli
Guest
Posts: n/a
 
      08-11-2005
(E-Mail Removed) wrote:
> >> Is it documented that lc() doesn't mind an undefined argument ?

> >
> >Not that I can see anywhere, but that certainly does seem to be the
> >case:

>
> Thanks, Paul, for the quick reply. If no one can assure me that
> this is documented behavior, I won't depend on it.
>
> Should this failure to warn be reported as a bug?
> If so, what is the best way to do that?


I'm not convinced that it is a bug. Unexpected and undocumented,
certainly. But I think a "bug" is something that directly contradicts
the documentation. I think this just qualifies as "undefined
behavior." Regardless, the proper way to submit Perl bug reports is
via perlbug. Read about its use at:
perldoc perlbug

Paul Lalli

 
Reply With Quote
 
Paul Lalli
Guest
Posts: n/a
 
      08-11-2005
Stephen Hildrey wrote:
> Paul Lalli wrote:
> > (E-Mail Removed) wrote:
> >>(BTW, about omitting the quotes, as in $hash->{Flag} :
> >> is this considered sound practice, or is it just lazy ?)

> >
> >
> > It could come back to bite you one day if: 1) a future release of Perl
> > suddenly introduces a Flag() function; 2) your code is modified to
> > include a Flag() subroutine; 3) your code is modified to import a
> > module which exports a Flag() subroutine; 4) your code is modified to
> > include a constant named Flag. If you're worried about one or more of
> > those, much safer to use the quotes.

>
> Not true.
>
> A simple expression (like a single token) inside the {} will
> automatically be treated as quoted, so the following:
>
> perl -w -MData:umper -e 'sub foo { return "bar"; } my %h; $h{foo} =
> "baz"; print Dumper(\%h)'
>
> will give the expected:
>
> $VAR1 = {
> 'foo' => 'baz'
> };


Hrm. I was just completely wrong. I was misremembering the docs.
Thanks very much for the correction. An my apologies to the OP for the
misinformation.

Paul Lalli

 
Reply With Quote
 
Stephen Hildrey
Guest
Posts: n/a
 
      08-11-2005
(E-Mail Removed) wrote:
> Is it documented that lc() doesn't mind an undefined argument ?


I can't see it documented, but it is a common idiom when using CGI.pm to
use:

my $foo = lc(param('foo'));

for exactly the purpose you describe - supressing the undef warnings.

I am not a Perl internals hacker, but at a guess (and I am probably
wrong) this source looks relevant:

if (!len) {
SvUTF8_off(TARG); /* decontaminate */
sv_setpvn(TARG, "", 0);
SETs(TARG);
}

(perl 5.8.6 - pp.c lines 3587 - 3591)

HTH,
Steve
 
Reply With Quote
 
Stephen Hildrey
Guest
Posts: n/a
 
      08-11-2005
Paul Lalli wrote:
> (E-Mail Removed) wrote:
>>(BTW, about omitting the quotes, as in $hash->{Flag} :
>> is this considered sound practice, or is it just lazy ?)

>
>
> It could come back to bite you one day if: 1) a future release of Perl
> suddenly introduces a Flag() function; 2) your code is modified to
> include a Flag() subroutine; 3) your code is modified to import a
> module which exports a Flag() subroutine; 4) your code is modified to
> include a constant named Flag. If you're worried about one or more of
> those, much safer to use the quotes.


Not true.

A simple expression (like a single token) inside the {} will
automatically be treated as quoted, so the following:

perl -w -MData:umper -e 'sub foo { return "bar"; } my %h; $h{foo} =
"baz"; print Dumper(\%h)'

will give the expected:

$VAR1 = {
'foo' => 'baz'
};

Similarly,

perl -w -MData:umper -e 'my %h; $h{print} = "baz"; print Dumper(\%h)'

will give the expected:

$VAR1 = {
'print' => 'baz'
};

Obviously clarity is the priority and if it is unclear what is going on
then either quote it or include a comment.

As to the use of constants, perldoc constant says it more succinctly
than I can:

"You can get into trouble if you use constants in a context which
auto-matically quotes barewords (as is true for any subroutine call).
For example, you can't say $hash{CONSTANT} because "CONSTANT" will be
interpreted as a string. Use $hash{CONSTANT()} or $hash{+CONSTANT} to
prevent the bareword quoting mechanism from kicking in."

Steve
 
Reply With Quote
 
Len@Weisberg.com
Guest
Posts: n/a
 
      08-11-2005
Paul Lalli wrote:
> Stephen Hildrey wrote:
> > Paul Lalli wrote:
> > > (E-Mail Removed) wrote:
> > >>(BTW, about omitting the quotes, as in $hash->{Flag} :
> > >> is this considered sound practice, or is it just lazy ?)
> > >


Thanks for the thoughtful discussion. Just to clarify:
So the upshot is that the use of barewords as hash keys is a sound
and
recommended practice?

Cheers,
-Len

 
Reply With Quote
 
Stephen Hildrey
Guest
Posts: n/a
 
      08-12-2005
(E-Mail Removed) wrote:

> Thanks for the thoughtful discussion. Just to clarify:
> So the upshot is that the use of barewords as hash keys is a sound
> and
> recommended practice?


It boils down to this: if your hash key is a bareword, you can leave out
the quotes; anything more complex as the key and Perl will interpret it
as an expression.

It's certainly a valid practice, whether it's sound and/or recommended
it probably a matter of taste. I'd argue "be consistent / be nice" here,
with a dose of "be understandable"

Steve
 
Reply With Quote
 
Tassilo v. Parseval
Guest
Posts: n/a
 
      08-12-2005
Also sprach Stephen Hildrey:

> (E-Mail Removed) wrote:
>> Is it documented that lc() doesn't mind an undefined argument ?

>
> I can't see it documented, but it is a common idiom when using CGI.pm to
> use:
>
> my $foo = lc(param('foo'));
>
> for exactly the purpose you describe - supressing the undef warnings.
>
> I am not a Perl internals hacker, but at a guess (and I am probably
> wrong) this source looks relevant:
>
> if (!len) {
> SvUTF8_off(TARG); /* decontaminate */
> sv_setpvn(TARG, "", 0);
> SETs(TARG);
> }
>
> (perl 5.8.6 - pp.c lines 3587 - 3591)


It's not really surprising that this behaviour is implemented somewhere
in the source. However, the code you quote is common in string handling
routines that usually upgrade undef to the empty string. The actual
check for emitting the warning normally happens before. But not in the
case of (uc|lc)(_first)? and possibly others for no apparent reason.

I'm inclined to say this is a bug unless someone is able to explain the
reasoning behind that behaviour.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=<=200);
 
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
How to pass a multiline arg to exec('some.exe arg')? n00m Python 5 05-05-2008 02:58 PM
typeof x == 'undefined' or x == undefined? -Lost Javascript 13 01-31-2007 12:04 AM
undefined vs. undefined (was: new Array() vs []) VK Javascript 45 09-12-2006 05:26 PM
Trouble with setTimeout(arg, arg) nat.hourt@gmail.com Javascript 7 11-12-2005 05:13 PM
undefined behavior or not undefined behavior? That is the question Mantorok Redgormor C Programming 70 02-17-2004 02:46 PM



Advertisments