[Mono-dev] [PATCH] System.Net.NetworkInformation

[Alan McGovern]

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 <jaebird at gmail.com> 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 <alan.mcgovern at gmail.com> 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 < jaebird at gmail.com> 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 at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > >
> > >
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070724/68eee904/attachment.html