In D6966#153160, @pfg wrote:

In D6966#153151, @email_piotr-stefaniak.me wrote:

I left out the array bound checks for now: they wouldn't hurt but I am not sure they are necessary

They prevent triggerable undefined behavior; the code in some cases works only by accident. I don't see a reason not to commit those fixes.

I am not against committing them, but I would like to see if there are alternatives.

I meant I want to give a thought on preventing such situations in a cleaner way.

In D6966#153151, @email_piotr-stefaniak.me wrote:

In D6966#153151, @email_piotr-stefaniak.me wrote:

I left out the array bound checks for now: they wouldn't hurt but I am not sure they are necessary

They prevent triggerable undefined behavior; the code in some cases works only by accident. I don't see a reason not to commit those fixes.

In D6966#153099, @bapt wrote:

@pfg already committed: rS303482, rS303483, rS303485, rS303489, rS303499

In D6966#152867, @email_piotr-stefaniak.me wrote:

In D6966#152751, @pfg wrote:

Very interesting: All the BSDs fixed the "typdef" typo but indent(1) generally needs much more attention.

That was when I mocked decades-old code for having a typo that nobody seems to have noticed all that time. Some NetBSD and OpenBSD people with commit bits noticed that and fixed it in their BSDs, FreeBSD then just copied that.

Very interesting: All the BSDs fixed the "typdef" typo but indent(1) generally needs much more attention. Plus the clang-format tool doesn't accept BSD style.

The Xen code may have it's own style guide but it might be good to check the style(9) manpage and perhaps the indent(1) example in /usr/share/examples.

Yes I had to revert a libedit upgrade affecting lldb.
It is good to less dependent on libedit's weirdness here.

The handling of srandom() looks good.

In D6257#143415, @avg wrote:

In D6257#140611, @pfg wrote:

This was committed as r300683 but phabricator didn't catch it.

BTW, I think that you should have Closed this request rather than Abandoned it.

Results form exp-run are good:

Perhaps this should be done for 11, and not later?

Forgot to include the man page change.

In D6733#141965, @ache wrote:

In D6733#141957, @pfg wrote:

I can't really do much to optimize the xorshift, and it doesn't seem like the LCG is being optimized away by the compiler.

Even if the code is called once per each CPU, I don't see this affecting seriously the startup time, but I have no good reason to pessimize sched_random() so abandon this revision. Thanks for the review!

You can make it faster than 24 times. Just use xor64() from the paper (with 64bit types) on amd64 machine and xor() you already use (with 32bit types) on i386. Maximum slowness should be about 2 times then. LCG can't be optimized away, computer just can't calculate such big loops as in my test while compiling.
For 64-bit machines there is another simple xorshift PRNG from Marsaglia paper:
unsigned long long xor64(){
static unsigned long long x=88172645463325252LL;
xˆ=(x<<13); xˆ=(x>>7); return (xˆ=(x<<17));

I can't really do much to optimize the xorshift, and it doesn't seem like the LCG is being optimized away by the compiler.