WARN <qof.engine> [guid_init()] only got xxxx bytes. The identifiers might not be very random.

[John Ralls]

On Mar 8, 2011, at 6:33 AM, Geert Janssens wrote:

> On dinsdag 8 maart 2011, Derek Atkins wrote:
>> Christian Stimming <stimming at tuhh.de> writes:
>>> Zitat von John Ralls <jralls at ceridwen.us>:
>>>>>> Can the qof guid library be replaced by libuuid on linux?
>>>>> 
>>>>> Those seem good proposals to me. The only (smallish) problem I see
>>>>> is that the
>>>>> guids generated by libuuid and UuidCreate have a slightly different
>>>>> format than what we use now. So we'd still have to wrap these
>>>>> libraries to output guids in the format we are using so far. But that
>>>>> seems to be a small issue.
>>>> 
>>>> That's the string value. We should just get the uint-128 and shove
>>>> it into the Qof structure and let Qof handle formatting it.
>>>> 
>>>> For completeness, the Quartz function is CFUUIDCreate(); it returns
>>>> an opaque CFUUID object, and you retrieve the value as a struct of
>>>> 16 uint8s with CFUUIDGetBytes().
>>> 
>>> Absolutely. I think at the time when gnucash adopted the GUID approach
>>> either libuuid wasn't around yet, or nobody thought of it at the time.
>>> I completely agree we should change the qof/guid.c implementation from
>>> our hand-written random number generator to libguuid on Linux and the
>>> two other methods on Windows and Mac, respectively.
>> 
>> My only concern is other platforms, platforms that might not have
>> libuuid, or platforms we don't currently "know about" (e.g. *BSD,
>> Solaris, etc).
> A quick google shows that libuuid is available on Solaris, FreeBSD, OpenBSD 
> and NetBSD. Any others I forgot ?
> 
>> My proposal would be to keep the code as-is (if it aint
>> broke, dont fix it) on all platforms except Windows -- where it truly is
>> broken.  On Windows, sure, change it to the Win32 API, but why rip out
>> working code elsewhere?  (Especially since we need to keep the code
>> around for other platforms anyways).
>> 
> Why change ? I would change this to keep the code easier to maintain. Other 
> guys have specialised in creating good uuid's. We are only consumers of 
> uuid's.
> 
> By the way other larger projects rely on libuuid as well like for example: 
> apache (verified both on solaris and linux).

It's part of libc on BSD. The include directive will be a little different, <uuid.h> instead of <uuid/uuid.h>. Interestingly, it's also in libc on OSX, but the header is Ted Ts'o's (of Linux fame) and it's at <uuid/uuid.h>. That means that we wouldn't need to use the CoreFoundation interface, which is nice.

On Debian, the header is in a separate, not-installed-by-default, package, uuid-dev, so configure will need to make sure it's there. That's probably true on most distributions.

I did see a note whilst googling around that it's an optional install on HP-UX, but does anyone still use HP-UX?

FWIW, dbus makes its own uuids by randomizing with the time as a seed. Very simple. There's also a comment that "it shouldn't be needed on Windows", and the code is ifdeffed out.

Regards,
John Ralls