[Mono-dev] Type.GUID patch

[Sebastien Pouliot]

Hello Robert,

On Sat, 2005-03-09 at 23:18 +0200, Robert Jordan wrote:
> Hi Sebastien,
> 
> >>The hash appears to change with the assembly name and type name.
> >>Renaming gt.cs will return another GUID as well as renaming
> >>"App". Renaming gt.exe doesn't change the GUID.
> >>Applying an AssemblyVersionAttribute will change the GUID,
> >>so I'm pretty sure, that Type.AssemblyQualifiedName is taken
> >>into account while generating the hash.
> >>
> >>The following algorithm computes the GUID from
> >>Type.AssemblyQualifiedName using a MD5 hash: 
> >>
> >>Guid ComputeGuid (Type t)
> >>{
> >>     byte[] bytes = System.Text.Encoding.UTF8.
> >>         GetBytes (t.AssemblyQualifiedName);
> >>     using (System.Security.Cryptography.MD5 md5 =
> >>            System.Security.Cryptography.MD5.Create ()) {
> >>         return new Guid (md5.ComputeHash (bytes));
> >>     }
> >>}
> >>
> >>Is it a patch worth?
> > 
> > 
> > I guess it depends on how it's gonna be used. This isn't the first time
> > people talks about Type.Guid but I never seen any talk about _using_
> > it ;-) at least not with Mono.
> > 
> > MD5 will give you a 128 bits digest value, which match the required Guid
> > length, and recent problems related to MD5 are pretty much irrelevant to
> > such usage. So it's probably (if everything is included in the qualified
> > name) a correct implementation - functionality-wise.
> > 
> > But creating a using MD5 is kind of heavyweight - even more if a new
> > instance is created each time. So anyone using this heavily will notice
> > a big performance problem.
> 
> MSFT's implementation (actually an InternalCall) is 3 times slower
> then the computation of an MD5 hash using an *unmanaged* implementation
> of the MD5 algorithm. 

Oh, that's interesting. How does this compare to your managed
implementation (using Mono's managed MD5 implementation) ?

> It's probably slower because it has to generate
> properly formatted UUIDs which consists of only 122 random bits.

I doubt that. Fixing the remaining bits is a very fast process (compared
to MD5). Anyway it's still interesting informations ;-).

> (see the 2nd link of Kornél's post).

I know about that, I changed Mono implementation based on this more than
a year ago :-)

2004-05-18  Sebastien Pouliot  <sebastien at ximian.com>

* Guid.cs: Fixed thread-safety issue. Simplified implementation to use
pseudo-random numbers to generate GUIDs (as per section 3.4 of the 
spec). This removes the TODO to get the computer MAC address and
the chances to get a duplicate GUID (across different machines).

> Ok, I don't think it's worthwhile to provide an unmanaged InternalCall
> for a property that obviously nobody uses.

I _totally_ agree with you on that :-)


Anyway my main point (beside the performance ;-) was that Mono's
Type.Guid won't be used for COM (at least not anytime soon) and since we
don't know how, or even if, this feature is gonna be used in Mono it's
difficult to know if your MD5 approach is correct or not.

Like Kornel said someone could depend, even for non-COM purpose, on the
specific value of a (generated) Guid. Yes that would be bad (on many
aspects) from any application but it would be easier to find this out
with an exception.
-- 
Sebastien Pouliot
email: sebastien at ximian.com
blog: http://pages.infinit.net/ctech/