createAlphaNumericUID() may not be unique


#1

I was just reading through the Projucer source for the first time. So much to learn from it!

I noticed that in jucer_Project.cpp on line 857, the method createAlphaNumericUID() is used without checking that the ID generated is unique to the Project. The probability of a duplicate may be very slim at numItemsInProject / 62^6, but not impossible…?

In comparison, in jucer_Project.cpp on line 973 a while loop is used to check that the result of createGUID is unique and re-generate as needed.


#2

I think the difference here is:

  • createGUID uses the passed string as the seed for the MD5 hash
  • createAlphaNumericUID uses a random seed based on the current system time

So in practice the probability for createAlphaNumericUID to create two colliding hashes is negligible, while createGUID creates colliding hashes if called multiple times with equal strings. The latter is quite likely, e.g. looking at https://github.com/julianstorer/JUCE/blob/master/extras/Projucer/Source/Project/jucer_Project.cpp#L990


#3

I did appreciate the difference in probability, but was still surprised by the lack of protection against the (very) low probability failure event.


#4

Actually this is the intended way to use GUIDs. You typically don’t want to check (or it’s not even possible) and instead assume no collision. Citing the wiki:

The application of the GUID is effectively premised on the assumption that a conflict will never occur, […] the user considers the benefits of its use to outweigh the potential consequences of a conflict, given the probability of that occurrence.

If a collision causes a “maximum credible accident” in some use case, then the GUID is just no proper tool.