Re: Back to emacsclient/server

[Juanma Barranquero]

On 10/28/06, Richard Stallman <address@hidden> wrote:

> Let's make (random 'random) generate a new seed, use it, then restore
> the old one, so that it has no effect on the sequence. This is a much
> smaller change than adding a means to read and set the random seed.

On one hand, both are really equivalent. To restore the old seed you
first need a way to get it. The current random code in sysdep.c tries
to massage wildly different random implementations (lrand48, rand,
etc.) into a consistent interface, and there's no support in place *at
all* for getting back the seed (which also varies quite a lot across
implementations of random functions). I don't think is very sensible
to hastily add now a mechanism for getting the seed which, to make any
sense, should have to be heavily tested in as much environments as
possible.

On the other hand, I don't quite get what you're proposing. Currently,
the output of (random t) is almost never used, because when you're
passing t you cannot pass N. In the Emacs sources, (random) is used
about 7 times, while (random N) is used approx. 70. But your proposed
(random 'random), if I'm understanding you, would save the seed,
return a value, then restore the seed. For that to be useful, it'd
have to be (random N 'random). Moreover,
the current `random', when passed t, does:

   seed_random (getpid () + time (NULL));

So in many situations, when several values are needed at once (as is
the case in server.el), the code using your 'random would be:

 loop N times
    save seed
    set seed to (getpid () + time (NULL))
    collect a random value
    restore seed
 end loop

I very much doubt the result is hardly random enough; in fact,
getpid() + time(NULL) is bound to return the same value for a lot of
consecutive calls... To make that useful we'd need a way to get N
values at once from random.

But I think that's all unnecessary right now. As others have pointed
out, several packages already do initialize the random seed for
trivial reasons; I see no harm in doing the same in server.el. If your
proposal (or any variant) is ever implemented, fixing server.el is a
one-line change.

                   /L/e/k/t/u