Struggling with the MD5 class between old and new version of Juce

#1

Of course a lot has changed since 1.53 but at the moment i'm trying to compare a MD5'ed String with Juce 1.53 with an MD5'ed String using the latest Juce tip. So i'm wondering it it's possible that the MD5 generated with Juce 1.53 could be different for the same string MD5'ed with the latest Juce version.

It's used in our registration system and i need to be able to load registration files created by older versions of our software (and thus older versions of Juce).

There are actually two issues here,  first of all when i call the following code (Note: i’m not interested in a MD5 of the file but of the path):

        String text = "/Users/Guest";

        DBG(MD5(text).toHexString());

 

This is the outcome:

JUCE v1.53.107 

Calls the explicit MD5 (const String& text)

a73cc4fa627b7fcdb07d95b71ccbef43

 

JUCE v3.0.2

explicit MD5 (const File& file); OOOPS! 

d41d8cd98f00b204e9800998ecf8427e

 

So in version 3 of Juce it's actually calling a different constructor, ouch.
So ok i might have been confusing myself here, but still whenever you pass a String in MD5 it will convert it to a File so i don't think that's the intended behaviour. If you are not checking the result for all zeroes you can get into troubles.

Ok so that can be fixed by specifying toUTF8 in the new code, but i get different values out for both versions, so i can’t compare them:

So when i call this in JUCE v1.53.107 :

        String text = "/Users/Guest";

        DBG(MD5(text).toHexString());


        text = “SomeTextToEncode”;

        DBG(MD5(text).toHexString());

 

This is the outcome:

JUCE v1.53.107 

Calls the explicit MD5 (const String& text) on "/Users/Guest"

a73cc4fa627b7fcdb07d95b71ccbef43

Calls the explicit MD5 (const String& text) on “SomeTextToEncode”

260fc1451c43685e5539d3c486d82e70

 

When i call the same code in JUCE v3.0.2 but specifying toUTF8():

        String text = "/Users/Guest";

        DBG(MD5(text.toUTF8()).toHexString());


        text = “SomeTextToEncode;

        DBG(MD5(text.toUTF8()).toHexString());

 

This is the outcome:

JUCE v3.0.2

Calls the explicit MD5 (const String& text) on "/Users/Guest"

a3d5f1f1613d82236d40ea9625d94bf6

Calls the explicit MD5 (const String& text) on “SomeTextToEncode”

9b615c941b6029e85b9bd44e9635fcca

 

So the hexstrings don't match up,  i should be able to rely on them being the same shouldn't i?

 

 

 

 

 

#2

Hmmm, i think i know what happened, it's actually calling the explicit MD5 (CharPointer_UTF8 utf8Text) constructor of course in JUCE v3.0.2. So it's encoding differently.

So that could cause the results to be different of course. Any idea on what i could do to use the new code to generate the same MD5 as the old code?

Still it would be good to have some warning with the File constructor being used when a String is passed in.

 

#3

Well I did make those constructors explicit to avoid people accidentally passing a String.. You shouldn't have just cast it to UTF8 without reading about exactly what that constructor does!

I can't remember exactly how the old code worked, but vageuly remember that it did an MD5 of the UTF32 encoding (?). If you look at the old code, you can probably just copy-and-paste the old method from it.

#4

Thanx Jules for the response, i was looking around and the fromUTF32 static method does exactly the same as the old String constructor.

String text = "/Users/Guest";
MD5 md5 = MD5::fromUTF32(text);
DBG(md5.toHexString());

This is working fine now...pfff

Quote:

Well I did make those constructors explicit to avoid people accidentally passing a String

Hmm, but get no warnings or anything when calling:

        String text = "/Users/Guest";
        DBG(MD5(text).toHexString());

it just calls the File constructor.
I mean i have a registration.h file that i copied over from the old version. I just compiled out of the box, of course i found out later that it returned different results but no warnings/errors were generated. So how could i have known? I mean the registration part is quite important so i gave it a good test but other mistakes are easily made this way. I mean one implicit conversion can be made right?
And there is a File constructor that takes a String, so the explicit keyword won't help in this case.

 

#5

Oh.. I'm surprised about that not causing an error.. Damned obscure C++ construction rules! Thanks for the heads-up - I might actually add a private constructor to prevent a String being used there accidentally.