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.
