Re: lc() with undefined arg
- From: "ced@xxxxxxxxxxxxxxxxxxxxx" <ced@xxxxxxxxxxxxxxxxxxxxx>
- Date: 12 Aug 2005 06:17:53 -0700
Tassilo v. Parseval wrote:
> Also sprach Stephen Hildrey:
>
> > Len@xxxxxxxxxxxx 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.
I was starting to believe it might be a bug but string operators
(at least the ones below) behave like the string function 'uc'
as well:
# neither emit a warning
perl -wle 'my $foo;print $foo .""'
perl -wle 'my $foo;print $foo x 3'
--
Charles DeRykus
.
- Follow-Ups:
- Re: lc() with undefined arg
- From: Tassilo v. Parseval
- Re: lc() with undefined arg
- References:
- lc() with undefined arg
- From: Len
- Re: lc() with undefined arg
- From: Stephen Hildrey
- Re: lc() with undefined arg
- From: Tassilo v. Parseval
- lc() with undefined arg
- Prev by Date: Re: difference in arrays/hashes
- Next by Date: Re: regex in perl (using variables)
- Previous by thread: Re: lc() with undefined arg
- Next by thread: Re: lc() with undefined arg
- Index(es):
Relevant Pages
|
|
