Re: Found a Perl hole

Replies are listed 'Best First'.
Re^2: Found a Perl hole by dragonchild (Archbishop) on Jan 27, 2005 at 18:00 UTC
`int(chr(127))` is equal to 0. `@x[$t]`, if @x doesn't have $t+1 elements in it, is undef, which is numerically equivalent to 0. Therefore, `int(chr(127)) == @x[$t]` will always be true, if @x doesn't have $t+1 elements in it. Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply] [d/l] [select]
Re^2: Found a Perl hole by shenme (Priest) on Jan 27, 2005 at 18:14 UTC
You have written quite a lot of code here. It is very confusing to us because of the great number of 'unusual' ways you implement things. 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: 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 [download] 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). 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: `@types[++$#types] = chr $temp; @types[++$#types] = int(rand(10));` [download] 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.	[reply] [d/l] [select]
Re^2: Found a Perl hole by graff (Chancellor) on Jan 27, 2005 at 18:38 UTC
I just was bsin at the int(chr(127)) part, ... I'm wondering what you think "int()" is supposed to do, because it looks like you expect it to do something other than "return the integer portion of a floating-point value." When you have the right notion of what "int()" really does, you should be able to understand why this little one-liner prints nothing but zeros -- and why that isn't a bug: `$i = int(chr(127)); printf("%d = %x = %o = %s\n",$i,$i,$i,$i);` [download] (and I wonder what "bsin" means...)	[reply] [d/l]