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

Reply via email to