[zeromq-dev] [PATCH] uuid_t source code significantly simplified

[Pieter Hintjens]

On Tue, Apr 26, 2011 at 3:05 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> What happens now is that foreign function is invoked to generate a binary
> UUID, afterwards it's converted into a string by another foreign function
> and then the string is converted back to binary by 0MQ.
>
> The whole show is performed just to ensure that the binary encoding of UUIDs
> on the wire is the same for all OSes and microarchitectures. If careful
> investigation is made, we can possibly avoid the two back and forth
> conversion steps.

Is there any proof that different architectures will cause collisions
in UUID space? Do we suspect that byte ordering affects the algorithm?

If not, I'd remove this code since solving theoretical (unreal)
problems is counter-productive.

It doesn't even require careful investigation, the lack of a proven
problem is IMO sufficient to remove any solution.

Here's some more on UUID collisions:
http://stackoverflow.com/questions/703035/when-are-you-truly-forced-to-use-uuid-as-part-of-the-design

-Pieter