Added patch to buzilla # 82403
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Ok, here is the patch for the System.Net.NetInformation.PhysicalAddress.
This is a big rewrite from the one revision 82491. I've also included a unit
test class (as there wasn't one) which passes all tests in both .NET 2.0 and
the patched version of PhysicalAddress. During the testing I found some
Fair enough :) (the hash code is a shift/add mangling approach) I didn't
realize I forgot my attachment! oops. Changed it to use straight elemental
compares and upon testing found other problems with the original class. So I
will do some more work on it and attach the patch tomorrow.
Thx,
Jae
_
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:
^
and
000 ^ .
As you can see [15, 120] is not eq
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 g
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.
F
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 mail
