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 be
smart enough to check its argument for define-edness
and throw a warning before stringifying it to ''.
print() will complain "use of uninitialied value in print"
double-quoted interpolation will complain
"use of uniintialized value in concatenation"
So, other functions check their inputs for defined-edness,
throw a warning, and then stringify to ''.
lc() appears to just stringify to ''.
Whether lc(undef) should return undef or '', I'm not sure.
It should throw a warning, at the very least.
when you string concatenate an undefined value,
my $var;
my $cat = "Hello, $var";
would you want $cat to be "Hello, " or would you want
$cat to be undef?
Former Ada programmers like myself might want a switch
that would return undef if any component is undef.
use strict::explosive_undefs;
This is actually how Verilog acts to some degree too.
(not as bad as Ada, but close). bits have 4 values during
simulation, 1,0,x,z. An x passed into any function will
come out an x too. This is actually extremely important,
since X's in hardware MUST be dealt with explicitely,
you cannot simply numify to zero and have it actually
work in silicon.
In hardware simulation, a single X can explode throughout
the entire chip, but it's actually what will happen in
silicon. If your voltage level is crap because you've
got contention between two opposing signals, it'll ripple
through all the transistors as a bad voltage (gates are
just transistors, and transistors are just amplifiers,
and amplifying a bad voltage will give you a bad voltage)
till you hit a flip-flop, which will then go meta-stable,
meaning it'll bounce from a 1 to a 0 to a 1 to a 0 for
awhile when it should be a stable memory bit,
and you suddenly have a random number generator.
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
