Andy Tompkins | 6 Dec 21:25
Favicon
Gravatar

Re: [Review] UUID library (mini-)review starts today, November 23rd

On Fri, 5 Dec 2008 10:44:00 -0500, "Scott McMurray"
<me22.ca+boost <at> gmail.com> said:
> On 2008-12-05, Andy Tompkins <atompkins <at> fastmail.fm> wrote:
> > On Tue, 2 Dec 2008 00:00:32 -0500, "Scott McMurray" said:
> >> I'd rather know whether it was v3 or v5 somewhere more obvious than
> >> the design notes, though.  If I were using v3 (MD5) uuids and
> >> switched to boost not knowing that v5 (SHA1) uuids exist, I'd
> >> likely be very confused when my code stops working with my data.
> >
> > Hmm, I'd be surprised if your code stopped working.
>
> Well, if I had some UUIDs in a database that were generated from a v3
> algorithm, and I tried to look one up from the base string, but
> generated the UUID from the v5 algorithm, the lookup would fail.

Ah, I understand.  Yes this would be a problem.

> Though I have no idea whether this would be an issue in practice.

Good question.  I don't know how boost::uuids can prevent this besides
documentation.

> > But regardless, would it be enough to add a/some member functions to
> > uuid so that one could ask what type of uuid it was?  For example:
> >
> > boost::uuids::version_type v = u.version();
> >
>
> I think that's an excellent idea.
>
> I don't think it solves the issue, though, since I likely wouldn't
> think to check going from some hypothetical old C API's
>
>     UuidCreateByName(&id, UUID_NAMESPACE_DNS, "www.widgets.com", 15);
>
> to
>
>     id = boost::uuids::uuid::create(dns_namespace_uuid,
>     "www.widgets.com");

I agree, it doesn't solve the issue.  I think the best guard against
this would be with unit tests for their code.

Regards, 
Andy Tompkins

Gmane