> "RN" == Ron Newman <[EMAIL PROTECTED]> writes:
RN> I've never really understood the rules for when it's "OK" to use
RN> undef as if it were 0 or "", and when it is "not OK" (generates a
RN> warning). Can someone summarize them, or point me to a reference?
without warnings enabled you
I've never really understood the rules for when it's "OK" to use undef as if
it were 0 or "", and when it is "not OK" (generates a warning). Can someone
summarize them, or point me to a reference?
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail
On Aug 12, 2004, at 11:31 AM, Greg London wrote:
Whether lc(undef) should return undef or '', I'm not sure.
It should throw a warning, at the very least.
FWIW, I agree it should at least throw a warning.
Returning undef from lc(undef) is 'what I expect'. But that behavior
would perhaps conflict wi
Greg London said:
> and you suddenly have a random number generator.
A little ASIC engineering trivia for you,
the technical term we use when that happens is
"a very bad thing"
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/lis
Hm, I'd have to agree that this is unexpected:
#
use warnings;
use strict;
if(defined(lc(undef)))
{ warn "defined"; }
else
{ warn "undefined"; }
#
This prints out "defined" and gives no warnings.
With warnings/strict on, I'd think lc should
On Aug 11, 2004, at 11:59 PM, Uri Guttman wrote:
BS> Is there a compelling reason why lc() and friends must return a
BS> defined value at all times? Just curious...
i think you have it backwards. lc forces string context upon its
argument and that will convert undef to ''. then it does its thin
6 matches
Mail list logo
