Re: rand48 replacement
От | Fabien COELHO |
---|---|
Тема | Re: rand48 replacement |
Дата | |
Msg-id | alpine.DEB.2.22.394.2107012209160.2248546@pseudo обсуждение исходный текст |
Ответ на | Re: rand48 replacement (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: