On Tue, 2008-09-30 at 17:51 -0400, James Carlson wrote: > Vladimir Kotal writes: > > random(3C) returns long which is 4 bytes in /usr/bin/nc (nc is delivered > > only as 32-bit prog). > > Actually, the random(3C) man page indicates that it returns a value in > the range 0 to 2^31-1. In other words, it's a 31 bit non-negative > value, and it doesn't matter how the application is compiled. > > > This means (random() & 0xFFFF) will be just the 2 > > less significant bytes of the 4 returned by random(). > > Yes, but why? > > > The purpose of the expression on line 792 is preparation for permuting > > the numbers in (lo,hi) interval. It seems that the goal of the binary > > operation is to cap the random number returned from random() to 16 bits > > (so it fits in the range of usable TCP/UDP ports) and then further limit > > it with the range 'hi - lo'. > > That sounds wrong to me. This code is tossing away 15 bits of the > randomness, and (much worse yet) is biasing the results. The first > 65536 - (65535 MOD (hi - lo + 1)) values will be hit preferentially, > something like (1 + 65536 / (hi - lo + 1)) times as often. That's > possibly an annoying skew, if the range is large, and it happens > precisely because the random value is truncated before being used for > the modulo (%) selection.
I can't follow exactly the thing with the introduced skew but the limitation of the range of possible numbers is not necessary in my opinion, since we only cycle through the number of ports in the range, not the ports themselves. Furthermore the number of ports is not limited to 64k, there can be ports in the list more than once (e.g. nc -z localhost 1-65000,5-65000 [if you want to try that find something else to do for the next hours ;-) ]). Erik _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
