Hello Tom,
Indeed. Here is a blind attempt at fixing the build, I'll check later to
see whether it works. It would help me if the cfbot results were
integrated into the cf app.
Hmm, not there yet per cfbot, not sure why not.
I'll investigate.
Anyway, after taking a very quick look at the patch itself, I've
got just one main objection: I don't approve of putting this in
port.h or src/port/. erand48.c is there because we envisioned it
originally as an occasionally-used substitute for libc facilities.
But this is most certainly not that, so it belongs in src/common/
instead.
Ok, this would make sense.
I'd also be inclined to invent a new single-purpose .h
file for it.
Hmmm. Why not.
I see that you probably did that because random.c and srandom.c
depend on it, but I wonder why we don't make an effort to flush
those altogether.
Ok for removing them. They are used in contrib where they can be replaced.
I hope that extensions would not depend on that, though.
It's surely pretty confusing to newbies that what appears to be a call
of the libc primitives is no such thing.
I do not understand your point.
If people believe the current random() implementation to be *the* libc
primitive, then my linux doc says "The random() function uses a nonlinear
additive feedback random number generator employing a default table of
size 31 long integers to return successive pseudo-random numbers in the
range from 0 to RAND_MAX. The period of this random number generator is
very large, approximately 16 * ((2^31) - 1).", which is pretty far from
the rand48 implementation provided in port, so ISTM that the confusion is
already there?
--
Fabien.
