I think it would help you if you would check some of your assumptions on how Perl code works. When in doubt I start up perl in the debug mode and try out a line or two. Such as:
This is me trying out that expression you were confused about. I find out that chr(127) does indeed convert the number into a string character. I then check what int(chr(127)) gives me - zero! Hmmm, doing an int() on a string that doesn't start with a number returns zero. Just to check what bart mentioned I try ord() and see that that is the reverse of what chr() does (which is why he mentioned it).perl -de0 Loading DB routines from perl5db.pl version 1.25 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 0 DB<1> x chr(127) 0 "\c?" DB<2> x int(chr(127)) 0 0 DB<3> x ord(chr(127)) 0 127
So I directly tested that part of the problem expression and find out it will _always_ give me zero.
But the array types doesn't always have numbers in it (so that '==' would be appropriate) nor does it always have characters in it (so that 'eq' would be appropriate). Compare these lines:
In the first you force the value to be a character, but in the second you ask for the value as an integer. So neither '==' nor 'eq' are going to always work for the values in @types.@types[++$#types] = chr $temp; @types[++$#types] = int(rand(10));
In reply to Re^2: Found a Perl hole
by shenme
in thread Found a Perl hole
by NewsToYou!
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |