rand() warmup

void init_random() {
    clock_t start = clock();
    int i = 0;
    while (clock() - start == 0) {
        i++;
    }
    srand(time(0) + i);
}

17±3 ms
Is it okay?

>>1
ONE WORD: THE FORCED WARMING OF THE CLOCK CYCLE

Why not just do something like this:

#include <stdlib.h>
#include <sys/timeb.h>
void init_random(void)
{
    struct timeb tp;
    ftime(&tp);
    srand(tp.time<<sizeof(short)*8 | tp.millitm);
}

What's wrong with srand(time(0));?

rand is so ridiculously bad anyway it doesn't matter what you seed it with.

>>2
I could rely on uninitialized memory too and/or memory location.
void init_random() {
    long seed;
    srand(time(0) + seed + (long)&seed);
}

>>3
It isn't portable.
Anyway, does portability matter? If not, I would use rdtsc.

>>4
time() returns seconds. Processes starting in the same second get the same seeds.

>>5
;__;

>>6
I think that I'll stick with
void init_random() {
    long seed;
    srand(time(0) + seed + (long)&seed);
}

I think the scheduling interference on clock() latency is “more” random, but I don't think I'll get much better results.


int fd  = open('/dev/random', O_RDONLY);
int num; read(fd, &num, sizeof(num);

PROFESSIONAL PROGRAMMING SOLUTION

>>8
Again, it isn't por... No, forget.

looping until the clock changes is a pointless waste of CPU time and a battery drainer for mobile devices.

clock may have a varying granularity which could be very fine or very poor.

for instance what if it is linked to a 100 hz interrupt timer? then you're burning 10 milliseconds, which is eons in modern computing cycles. (how often will your program run; is it scripted?)

OTOH if the clock is very fine, maybe your i++ will never execute b/c it may take longer to call clock than the time between successive values.

here are some other ideas. forget about strictly standard C and help yourself to some additional functions. for instance, you could call the POSIX gettimeofday, or even the newer clock_gettime to get a finer grained real time with microseconds or nanoseconds.  you could get the process id with getpid and mix that in also.

on windoze you have GetTickCount which is milliseconds since the system started (not process virtual time like clock). I think mingw has gettimeofday.

>>8

sorry, that's a poor idea. /dev/random is a source of real randomness. so that means two things.

one, you're wasting  good random numbers on seeding this POS  prng in the standard C library which is not suitable for any applications that actually need real randomness, like crypto.

secondly /dev/random is a blocking device on linux. it will pause your program if not enough random bits are available until the system gathers enough. by stealing these bits, you make other programs block, ones which need it, like crypto stuff.

you want /dev/urandom, which is a nonblocking device that produces a sequence of pseudo-random bytes seeded from random bytes.

>>7

there is no guarantee that the uninitialized variable provides useful random bits.  it is very possible that it may have the same behavior each time your run the program and so it adds nothing. i.e. you're not necessarily overcoming the problem that time(NULL) may return the same number when the program is run several times in a script.

>>10-12
Oh, thank you!
For mobile/embedded applications, what about mixing some sensors status data (batt charge, temps, RF bg noise)?

>>13
If you could get ahold of a GPS signal, it has a lot of noise added in by the US Govt. RF noise is fine as well. Although, generally, the higher level of entropy you try to attain, the greater the power strain.

>>13
While using real-world data in your randomness is great, if it's entirely from things that the user can very potentially influence, you might have issues with users being able to 'control' your randomness. Albeit that's a bit of a far stretch, depending on what sensory input you use and how you use it.

>>15 Long before you worry about stuff like that, you stop using the C library rand/srand!!!

>>1
still, wouldn't two processes that start at the same get the same seed? next value on time()?