|
|||||||||
|
|||||||||
| |||||||||
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| ||||||||||||||||||||||||||||||||
 |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
Dev Shed Forums Sponsor:
|
|
|
|
#1
August 15th, 2008, 03:56 PM
|
||||
|
||||
|
Perl puzzle of the week/month/year
Ok, we haven't done one of these in a while. I'll keep this one short and sweet.
Code:
#!/usr/bin/perl -w $foo = "0 but true"; $bar = $foo + 5; print "$bar\n"; Run this and it'll run fine: Code:
mb@motorhead:~/perl> ./funny_perl 5 Now change the $foo line to: Code:
#!/usr/bin/perl -w $foo = "1 but true"; $bar = $foo + 5; print "$bar\n"; and run it and you'll see a warning: Code:
mb@motorhead:~/perl> ./funny_perl Argument "1 but true" isn't numeric in addition (+) at ./funny_perl line 5. Now change the $foo line to: Code:
#!/usr/bin/perl -w $foo = "0 but false"; $bar = $foo + 5; print "$bar\n"; and run it and you'll see a warning: Code:
mb@motorhead:~/perl> ./funny_perl Argument "0 but false" isn't numeric in addition (+) at ./funny_perl line 5. So your question is: Why does the first program not emit a warning when the other two do? EXTRA BONUS: Is there a reason behind this madness? Usual puzzle rules apply -- * Answer will be supplied next Friday, if no one can solve it by then. * Winner will be determined by me and the person(s) replying with the first correct answer will win fame by having their name in green letters in my signature until I decide what the next contest is. * Judge's (namely me) decision is final  .* There is no fight club.
__________________
Up the Irons What Would Jimi Do? Smash amps. Burn guitar. Take the groupies home. "Death Before Dishonour, my Friends!!" - Bruce D ickinson, Iron Maiden Aug 20, 2005 @ OzzFest Down with Sharon Osbourne Puzzle of the Month solved by Fishmonger, superior perl programmer of the month Last edited by Scorpions4ever : August 15th, 2008 at 03:59 PM.
|
|
#2
August 15th, 2008, 04:25 PM
|
||||
|
||||
|
Easy.
There is a bug in the -w functionality of the perl interpreter. Pfft. 
__________________
Bugs that go away by themselves come back by themselves Never take life seriously, Nobody gets out alive anyway.
|
|
#3
August 15th, 2008, 04:46 PM
|
||||
|
||||
|
If a string starts with a number, perl evaluates it as a number (when used in a numeric context) up to the first character that doesn't make sense as a number. A warning was still generated to show there may be something more in the string to be concerned about. Doesn't stop program execution though.
However, the string "0 but true" is a special case built into perl. Code:
#!/usr/bin/perl -w use strict; my $r = '0 but true'; print "r is true\n" if $r; print "r is zero\n" if $r == 0; You could return that string from a routine to show that while there were no results, there was also no error. Similar to how the DBI module returns "0E0", which acts in the same way. Means there were no rows affected, but evaluates as 'true'; no error occurred. Last edited by keath : August 15th, 2008 at 04:54 PM. Reason: oops, I changed my variable names
|
|
#4
August 15th, 2008, 08:23 PM
|
||||
|
||||
|
Keaths answer explains a lot, but not quite why the first program does not issue a warning, the answer to that is:
Quoted from perldoc: Quote:
Am I splitting hairs? Definetly. 
|
|
#5
August 20th, 2008, 07:12 PM
|
||||
|
||||
|
Boy, you guys are good.
Also, the reason for "0 but true" is because of a few *nix functions (such as ioctl() and fcntl()). When Larry wrapped these around perl built-ins, he had a problem because 0 is a valid return value for these C functions (they return -1 on failure and 0 or +ve values on success). Now you couldn't do this in perl anymore, if the functions returned 0: Code:
ioctl($fd, $what, $value) or die "ioctl() no workie\n"; So he made these functions return "0 but true" when the underlying C code returned 0, so code like the above would work. BTW this type of issue is called the semi-predicate problem. I first saw the "0e0" in DBI, but Mark Jason Dominus' book also mentions it as a way around the problem. Larry just used "0 but true" to work around it instead of "0e0". Then he hacked perl so that it would specifically NOT warn if you tried to do arithmetic with "0 but true". It is an ugly hack, but no one said that Larry was sane. Full marks to Keath and KevinADC for getting the answer correctly.
|
|
#7
August 9th, 2009, 11:44 AM
|
||||
|
||||
|
time for a new one?
__________________
--Ax without exception, there is no rule ... Heavy Haulage Ireland Targeted Advertising Cookie Optout (TACO) extension for Firefox The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones  09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. -- Jamie Zawinski Detavil - the devil is in the detail, allegedly, and I use the term advisedly, allegedly ... oh, no, wait I did ...
|
|
#8
August 9th, 2009, 02:46 PM
|
||||
|
||||
|
Sounds like a plan. I'll post a new one tomorrow, when I get to work.
|
|
| Viewing: Dev Shed Forums > Programming Languages > Perl Programming > Perl puzzle of the week/month/year |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
 |
|
|
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
