| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
on myself to do something about the non-self-consistency of the inet
comparison functions. The results are probably still semantically wrong
(inet and cidr should have different comparison semantics, I think)
but at least the boolean operators now agree with each other and with
the sort order of indexes on inet/cidr.
|
| |
|
|
| |
now TOAST-able.
|
| |
|
|
|
|
|
|
| |
WARNING: This is actually broken - we have self-deadlocks
due to concurrent changes in buffer management.
Vadim and me are working on it.
Jan
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
| |
integers) to be strings instead of 'double'. We convert from string form
to internal representation only after type resolution has determined the
correct type for the constant. This eliminates loss-of-precision worries
and gets rid of the change in behavior seen at 17 digits with the
previous kluge.
|
| |
|
|
|
|
| |
This is because (-1) << 32 is -1 (Only intel arc. has been checked)
Oleg Sharoiko
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
198.68.123.0/27 the same when indexing them.
D'Arcy
|
| | |
|
| |
|
|
|
| |
mis-copied "NULL", which happens to have the same binary value.
Previously, gcc gave non-fatal warnings.
|
| | |
|
| |
|
|
|
|
|
|
| |
portability problem. Included patches should be applied to both
current and 6.4 tree. I have tested on LinuxPPC, FreeBSD and Solaris
2.6. Now the inet regression tests on these platforms are all happy.
---
Tatsuo Ishii
|
| | |
|
| |
|
|
| |
testing for null-pointer return code...
|
| | |
|
| |
|
|
|
|
| |
(Someone forgot whether their subroutine signaled errors by a NULL pointer
return value, or a negative integer... I'm surprised gcc -Wall doesn't
catch this...)
|
| |
|
