6 Dec 21:25
Re: [Review] UUID library (mini-)review starts today, November 23rd
Andy Tompkins <atompkins <at> fastmail.fm>
2008-12-06 20:25:27 GMT
2008-12-06 20:25:27 GMT
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
RSS Feed