[Mono-devel-list] GetHashCode () differences from Microsoft

[Ben Maurer]

On Wed, 2003-06-04 at 05:03, Paolo Molaro wrote:
> On 06/02/03 Ben Maurer wrote:
> > As you may know, I am running the Rotor Test Suite (found under
> > /test/bcl/system in the sscli directory). I noticed that there are many
> > differences between our GetHashCode methods and the ones in Microsoft's
> > corlib.dll. This causes many of the Rotor tests to fail. Some examples
> > of items that are failing are the GUID stuff and the char tests.
> 
> If the tests break because of the different GetHashCode() algorithm, the
> tests are broken.
> 
> You can certainly make those kind of changes to your local cvs tree,
> but those changes should not be committed. The right thing to do is
> to fix the tests to not depend on a particular GetHashCode()
> implementation. 
Is there any disadvantage to committing them? Would it do any harm?

The reason I would like to get this stuff "fixed" is because I think
that the Rotor tests can give us some very valuable data. It is a very
through test suite, and is a great test of our progress. However, if we
start to modify the code, it becomes less valuable. No longer will it be
possible to see that mono is working correctly by running the external
test suite.

I also think that the tests could provide some great marketing power.
When we get 100% of the tests to pass, I am sure it will be newsworthy.
However, 100% (with tests modified where we think Microsoft is wrong) is
not quite as spiffy.

Because Rotor is designed as an ECMA compliant implementation of the
framework, maybe we want to use the Microsoft methods when we are
compiling for ECMA compatibility (that is, if we ever do that).

> As for looking at the rotor code, since you're not a
> lawyer, nobody should trust what you say about what the rotor license
> allows to do. We should stay on the safe side and pseudo code notes
> are not, unless done by someone external to mono, IMHO.
Of course I am not a lawyer, and of course that means you should not
trust me! However, I have some good sources
(http://www.southern-storm.com.au/pnet_faq.html#q10_5).

>From that:

> On the copyright side, our responsibility is the same as it would be
> under any other circumstances: we must write all our code from
> scratch, copying nothing contained in their Rotor code. If there is no
> copying there is no infringement under their license. [...]
> 
> Where (which is likely to be everywhere), ECMA is insufficiently
> descriptive to create interoperable code, it is acceptable to read the
> source of the Rotor implementation. Notes taken in the course of
> reading that source should be made in pseudocode [...] Ideas
> abstracted from the Rotor implementation should always have been put
> in our programmer's own "words," because copyright protects
> expressions, not ideas.

That seems pretty clear to me.