Depending upon the implementation-specific time representation used
for time_t, that expression might generate only a small number of
different seed values, or it might generate seed values that change
excessively slowly with time. What you typically need in that context
is an expression that generates a different seed value each time you
run the program, and has a roughly equal chance of generating every
permitted seed value.
To minimize dependence upon the representation of time_t, I'd
recommend something like this:
#include <limits.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
srand(fmod(difftime(0, time(NULL), UINT_MAX+1.0));
That will use different seed values at the rate of 1/second, which
should be good enough for many purposes.
one option I have used:
implement a custom prng, with a larger internal state, for example, 4096
bits (reason: rand does not necissarily have all that large of an internal
state, and is thus not really good for some uses);
the initialization function can load the seed from a file, use the 'time'
trick, rehash the seed or similar, and store it back out to the file (thus
each run hopefully adding a little more entropy).
if done well, with any luck, this gives at least some semblence of
randomness.
rand is useful for some things (where the actual randomness isn't all that
important, or only applies to a small range).
but, when using it for some other things, for example, generating largish
presumably unique values (GUID-like values, ...) one hopes for something
hopefully a little more 'random'.
for example, if it only has about 32 or 48 bits of entropy, what good is it
to try to generate , say, 96 bit unique values. there will be, at most (and
probably much less) 2^32 or 2^48 different values.
a slightly larger entropy, say, 2^4096, is a little more sane for this kind
of use.
or such...
now, here is another possibly interesting (mostly hypothetical) problem:
open-source copy protection.
goal: a copy protection scheme which will still work, even when the user has
full ability to look at, modify, and recompile the source (and, thus, it
can't be based on obscurity, or something which the user can simply bypass
or comment out).
I have some possible ideas here, but I will keep them to myself...