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?