OSDN Git Service

Sorting for the inet data type randomly returns the wrong result
authorBruce Momjian <bruce@momjian.us>
Tue, 7 Mar 2000 23:01:43 +0000 (23:01 +0000)
committerBruce Momjian <bruce@momjian.us>
Tue, 7 Mar 2000 23:01:43 +0000 (23:01 +0000)
commit52d39d519a97f7f501e47cdabda61fa3d3477fb8
tree452da9e8a1aa9f171d71551cc60d9b477aee6673
parent5a197810c09da06a772c235a6bba68290745d74c
Sorting for the inet data type randomly returns the wrong result
when you have networks with the same prefix, but different netmasks.

This is due to the fact that occassionally there is random
(uninitialized?)
data in the extra bits past the point where the netmask cares about
them.

ie (real data from a real live database):

  10.0/10 == 00001010.00100000.00100000.00011000
  10.0/11 == 00001010.00000000.00000000.00000000
                        ^ Bad data, normally never seen

The v4bitncmp() function was only taking one bit length argument so
it would determine that the networks were different, even though
they really aren't (and the netmask test wouldn't be used).  This
ONLY happens if the tuple with the longer bit length is used as the
ip_bits() for the v4bitncmp call AND there happens to be junk data
in place in the shorter tuple.  Odd and random, but I saw it happen
a couple times so...

Ryan Mooney
src/backend/utils/adt/network.c