• Mijzelf (unregistered)

    And how big is the chance to be frist?

  • Eilert (unregistered)

    Frist?

    This is not spam. Or is it?

  • (cs)

    Infinite loop?

  • Accalia.de.Elementia (unregistered)

    okay.... who hacked Remy's account? there are no funny html comments!

  • (cs) in reply to Accalia.de.Elementia

    It's hard to work HTML comments into CodeSODs. It's more of a feature article thing. Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article. ahem

  • (cs) in reply to Remy Porter
    Remy Porter:
    Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article. *ahem*
    Mark and Alex whistle very casually.
  • Accalia.de.Elementia (unregistered) in reply to Remy Porter

    Ah! I found the TRWTF: IE!

  • (cs) in reply to Remy Porter
    Remy Porter:
    Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article.
    People use IE for anything? Willingly?
  • (cs)

    The MSDN documentation for the NewGuid method says only that the chance of a duplicate value is "very low." They should update their docs with the hit-by-a-meteor-during-Lent analogy.

  • YR (unregistered)

    Where's the WTF? That's totally justifiable! I never felt too comfortable about random values that are this likely to collide.

    Cheap bastards, we have plenty of memory and storage capacity, and you use 128 bit random crap?!? We should move to 1 Gbit, at the very least!

  • Chelloveck (unregistered)

    The API here is TRWTF. You need to call two different GUID generators depending on whether or not this is the first GUID, and you have to keep a list of all your GUIDs around? Who designed this? There should be a single function which takes no parameters and internally stores all the GUIDs it generates. Bonus points if the list of GUIDs is persistent across runs so it can verify that it never duplicates a GUID. But that may be outside the scope of this problem.

  • (cs) in reply to Chelloveck

    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

  • (cs) in reply to YR
    YR:
    Where's the WTF? That's totally justifiable! I never felt too comfortable about random values that are this likely to collide.

    Cheap bastards, we have plenty of memory and storage capacity, and you use 128 bit random crap?!? We should move to 1 Gbit, at the very least!

    Excessive troll is excessive.

  • YR (unregistered) in reply to Remy Porter
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    NO WAI!

  • Infinite Time and Space (unregistered)

    My understanding is the the current date and time is incorporated into the GUID, so no matter what, the context in which this code is used could never have duplicates in the first place. To have a duplicate GUID basically requires two different apps (or threads) on the same machine create a GUID at the same time, and then also be very lucky (or unlucky).

    But it is easier to write the code than to read documentation about GUIDs

  • Meep (unregistered)

    Or you could, you know, use natural keys and avoid all this nonsense.

    But that would be too easy, I guess.

  • (cs) in reply to Meep
    Meep:
    Or you could, you know, use natural keys and avoid all this nonsense.

    But that would be too easy, I guess.

    Above all, it would not be enterprisey!

  • Andrew Stein (unregistered)

    I hope that none of you ever have the joy of generating GUIDs in parallel using Oracle on AIX. See Andy Hogg's excellent analysis at http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

  • (cs) in reply to Andrew Stein

    Now that's the real WTF. That's also a reason one of the forums is the "I hate oracle club".

  • Sten (unregistered)

    I see the problem is that GUIDs are only globally unique. This programmer obviously thought of poor Martians and other extraterrestrials forced to place interplanetary calls to have this fixed (the prices are just insane). On the other hand, he could simply use univerally unique UUIDs :-)

  • Tim (unregistered)

    regular readers will now there's a perfectly simple to ensure your guid is really unique: just take an existing guid and swap the first 2 characters round

    http://thedailywtf.com/Articles/A-More-Unique-Identifier.aspx

  • She sapped me of my precious bodily guids (unregistered)

    GUIDs take up too much space. Use integers:

    Guid.NewGuid().ToString().GetHashCode()

  • Captcha: opto (unregistered) in reply to Remy Porter
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.
    In fact, adding elaborate code like this INCREASES the chance of running into duplicate GUIDS enormously, as it raises the probability of having bugs in it.

    Chance of running into a duplicate GUID ≈ chance of having a bug in your code that deterministically generates duplicate GUIDs.

  • Shawn H Corey (unregistered)

    You because you're not paranoid doesn't mean computers don't hate me!

  • rohcQaH (unregistered)

    It'll only compare to a small set of GUIDs the caller knows about, not to every other GUID ever issued on this planet.

    So it's actually a LUGUID: Locally Unique GUID.

  • (cs)

    The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

    To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

    I could calculate the chance of a collision, but I have better things to do :-)

  • jim (unregistered)

    usually, a system will have a lots of guids, tons of em. Going through that array of guids each time one needs a new guid is going to eat some serious time. In a smaller system, that might be OK.

    In a larger system. If you are adding a new guid pk's row to a table, it might be quicker to jst catch the duplicate pk error and re-assign the guid at that point.

    Peace,

    Jim

  • spike (unregistered)

    TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

  • Jason (unregistered)
    while driving your Ferrari to the diner for pancakes
    I don't eat pancakes for dinner, you insensitive clod!
  • (cs)

    Another way of looking at it, is that there are apparently about 1.33 * 10^50 atoms in the whole planet, and if you were to break the planet down into chunks the size of a grain of sand (about 8 * 10^19 atoms each) you would have about 1.66 * 10^30 grains and could label each of them with a GUID and only use 1/300000th of a percent of the available ones.

  • MightyM (unregistered) in reply to She sapped me of my precious bodily guids
    She sapped me of my precious bodily guids:
    GUIDs take up too much space. Use integers:

    Guid.NewGuid().ToString().GetHashCode()

    Wow, just wow.

    (Obligatory Eric Lippert link: http://blogs.msdn.com/b/ericlippert/archive/2010/03/22/socks-birthdays-and-hash-collisions.aspx)

  • (cs) in reply to spike
    spike:
    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)
    That used to be the case, but according to Microsoft (and the same seems to apply to *nix systems too)
    Microsoft:
    For security reasons, it is often desirable to keep ethernet addresses on networks from becoming available outside a company or organization. The UuidCreate function generates a UUID that cannot be traced to the ethernet address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer.
  • That guy over there (unregistered)

    I don't think it's that bad of an idea. The birthday paradox combined with a shitty random number generator could easily result in collisions.

  • HERO OF THE GUID (unregistered)

    If they had used a more secure GUID they wouldn't have to worry about collisions:

    http://rubbishsoft.com/libraries/longguid

    FUCK YOU AKISMET YOU FANFARE OF DIARRHEA

  • PRMan (unregistered) in reply to spike
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

    Actually, not anymore. Now they are almost completely random.

    I worked at a company where we actually got a duplicate that couldn't be explained any other way except that it was a generated duplicate. This is when I learned that the generation method had changed.

  • Esse (unregistered)

    I'm having some problem understanding the code.

    What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

    Shouldn't the method reloop everytime a new GUID is generated and assigned?

  • Some Jerk (unregistered)

    He should use a dictionary to increase performance over the .Any() call.

  • (cs) in reply to GettinSadda
    GettinSadda:
    The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

    To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

    I could calculate the chance of a collision, but I have better things to do :-)

    Running out already? Goodness! We need to sort this one out! Quick, where are my developers? All leave cancelled till you sort this out! GettinSadda has just told me the GUIDs are running out!

  • Some Jerk (unregistered) in reply to PRMan
    PRMan:
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

    Actually, not anymore. Now they are almost completely random.

    I worked at a company where we actually got a duplicate that couldn't be explained any other way except that it was a generated duplicate. This is when I learned that the generation method had changed.

    Not this shit again...

  • Bananas (unregistered) in reply to Chelloveck
    Chelloveck:
    The API here is TRWTF. You need to call two different GUID generators depending on whether or not this is the first GUID, and you have to keep a list of all your GUIDs around? Who designed this? There should be a single function which takes no parameters and internally stores all the GUIDs it generates. Bonus points if the list of GUIDs is persistent across runs so it can verify that it *never* duplicates a GUID. But that may be outside the scope of this problem.
    Not good enough. The list of GUIDs it checks against and adds to needs to be in the cloud so that no GUID ever used anywhere in the world/galaxy/universe is duplicate.
  • Recursive Reclusive (unregistered) in reply to Esse
    Esse:
    I'm having some problem understanding the code.

    What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

    Shouldn't the method reloop everytime a new GUID is generated and assigned?

    I believe there are two loops in there. An inner loop, "guids.Any(g => g == result)", that goes through all GUIDs and return true or false. And an other loop, "while", that continues until the inner loop return false.

    In reality, the inner loop will always return false, so the while-loop is only executed once.

  • Slicerwizard (unregistered)

    "struck by a meteor and lighting"

    Lighting what?

  • (cs)

    As far as real WTFs go... the idea of insuring distinction is perhaps a bit OCD but not uncommon among us home grown developers, where college developers started with facts regarding probability and origins before moving on to code. This isn't a mistake I have made before, but there are times when my comfort level with how the target computer will react to my assumptions causes me insert additional functionality which is not likely to be needed. Either way, I can get behind anything that accounts for Murphy's Law, so although I believe that check to be a bit redundant or (as I said before) OCD, I wouldn't classify THAT part as entirely a WTF.

    What I do see as a WTF is the architecture that this coder believes "necessitates" said functionality.This architecture is supporting 3 entities? Or even 3 million, it doesn't matter, though ParamArray may be a silly idea if it is.

    If the construct is resident in memory and not serialized, then surely a static incriment structure would work fine. If it is serialized in RDBMS AND necessitates a Guid, then surely the database would be an ideal spot for producting the Guid, and preserving uniqueness. If it is serialized to a file, then would not a date stamp be enough?

    My point is... I cannot picture an infrastructure where this implimentation would be useful or necessary.

  • (cs) in reply to Recursive Reclusive
    Recursive Reclusive:
    Esse:
    I'm having some problem understanding the code.

    What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

    Shouldn't the method reloop everytime a new GUID is generated and assigned?

    I believe there are two loops in there. An inner loop, "guids.Any(g => g == result)", that goes through all GUIDs and return true or false. And an other loop, "while", that continues until the inner loop return false.

    In reality, the inner loop will always return false, so the while-loop is only executed once.

    Not so... :p

    guids.Any will return true only if the newly created Guid is already in the ParamArray, and if so, creates a new one. It's basically like replicating SQL In Operator -- if @intVal in (1, 2, 3) -- yielding true where @intVal is either 1, 2 or 3...

  • She sapped me of my precious bodily guids (unregistered) in reply to MightyM
    MightyM:
    She sapped me of my precious bodily guids:
    GUIDs take up too much space. Use integers:

    Guid.NewGuid().ToString().GetHashCode()

    Wow, just wow.

    (Obligatory Eric Lippert link: http://blogs.msdn.com/b/ericlippert/archive/2010/03/22/socks-birthdays-and-hash-collisions.aspx)

    Here, this is twice as secure (and a better troll):

    Guid.NewGuid().ToString()Guid.NewGuid().ToString() + Guid.NewGuid().ToString()).GetHashCode()

  • (cs)

    Of course it is doing a linear search which ends up being O(N²) to create N guids, and I am assuming this is measured forever, so each time you create a new one you have to check every GUID ever previously created.

    It would be interesting to know what they are creating a GUID for. A temp directory / filename is one thing I have used a GUID for. Also for a unique transaction ID in a client-server situation for messaging.

    With the temp file, the filesystem will probably check its uniqueness for you. With the messaging system there is almost certainly some kind of lookup map you use because the GUID, which has the letters "ID" in it for a reason, acts as a unique "primary key" for the data underneath. So you will get some kind of error if it already exists without having to go through such a check.

  • Canada, eh? (unregistered) in reply to Slicerwizard

    Since you're driving, I would assume some kind of roadside lighting. Like a street lamp or billboard floodlight.

  • sagaciter (unregistered) in reply to Slicerwizard
    Slicerwizard:
    "struck by a meteor and lighting"

    Lighting what?

    If you were struck by a meteor you probably would light.

  • (cs) in reply to Mijzelf
    Mijzelf:
    And how big is the chance to be frist?

    I've achieved that aim several times, now I wish to get a comment with a blue background and appearing with the article.

  • (cs) in reply to That guy over there
    That guy over there:
    I don't think it's that bad of an idea. The birthday paradox combined with a shitty random number generator could easily result in collisions.

    Whatever the WTF of checking that a GUID generated really is unique, the method of doing so is definitely a WTF.

    A GUID only really needs to be unique in its context too. If you use GUIDs in different contexts it doesn't really matter if they match. A bit like having the same primary key but for different database tables..

Leave a comment on “GUGUID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article