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

[Geert Janssens]

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).

Geert