Fair enough, but it *will* give false positives. If the XOR operation was used on the address bytes (which i assume it would be) then you have the problem that the following two sequences generate the same hashcode:
00001111 ^ 11110000 and 1111000 ^ 00001111. As you can see [15, 120] is not equal to [120, 15] yet they both XOR to give 255 as the hash code. So, my advice is to change the patch to *not* use the hash code to determine equality and then attach it to an email or a bugzilla report indicating what incompatibilities it fixes. You never attached it in your first email. Alan. On 7/24/07, Jae Stutzman <[EMAIL PROTECTED]> wrote:
Quite possible, it was a quick pass. The GetHashCode() is overridden to provide its answer based on the underlying address bytes. On 7/24/07, Alan McGovern <[EMAIL PROTECTED]> wrote: > > Doing a comparison by comparing the hashcodes sounds very broken to me. > It's quite possible for two objects to give the same hashcode without > actually being equal. > > Alan. > > On 7/24/07, Jae Stutzman < [EMAIL PROTECTED]> wrote: > > > > This small patch makes the Equals(...) override more like MS behavior. > > First if both addresses are empty it returns true, also the comparison now > > uses the hashcode. This was changed as part of the porting a windows .net > > app. > > > > Jae > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
