time

[Bill Cunningham]

Maybe adding process ID to the seed calculation would do the job.

Instead of:

srand(time(NULL))

Use:

srand(time(NULL) ^ getpid())

Or even:

srand(time(NULL) ^ (getpid() << 16))

Is that really that random? As long as a process has fork() 'ed and the
process is running it's pid isn't going to change is it until the system
kills it.btw to stay on-topic here that caret and those << indicators. I've
never seen that in C except maybe headers. Are they preprocessing tokens?

Bill

 

[osmium]

btw to stay on-topic here that caret and those << indicators. I've never
seen that in C except maybe headers. Are they preprocessing tokens?

K&R has one of the best indexes I have ever seen in a technical book. It
starts on p 263. But the whole point of writing a book is for people to
*read* it. Try it some time.

 

[Keith Thompson]

Is that really that random? As long as a process has fork() 'ed and the
process is running it's pid isn't going to change is it until the system
kills it.

You only call srand() once during the execution of the program.

btw to stay on-topic here that caret and those << indicators. I've
never seen that in C except maybe headers. Are they preprocessing tokens?

^ is the exclusive-or operator. << is the left-shift operator.
You'll find both in the index of the C standard and of K&R, which
you could have checked before wasting everyone's time by asking
about it here.

 

[Bill Cunningham]

You only call srand() once during the execution of the program.


^ is the exclusive-or operator. << is the left-shift operator.
You'll find both in the index of the C standard and of K&R, which
you could have checked before wasting everyone's time by asking
about it here.

Oh yes that's right. I was thinking shells and posix in this discussion
about arc4random. The bit-wise operators ok I know what they are. Fell
asleep for a minute.

Bill

 

[Nobody]

Maybe adding process ID to the seed calculation would do the job.

It would, and that's common. But there's no portable way to read the PID
(if such a concept even exists on a given platform).

The main issue is that time() appears to be about the only portable source
of non-determinism available, and it's typically rather weak.

If it's worth going to that much trouble, it's probably worth using a
better random number generator than rand() (one provided by the
implementation but not specified by the C standard).

But that doesn't do anything about the lack of non-determinism (entropy).
A better PRNG may give you better random numbers, but without something
other than time(), they'll be exactly the same random numbers as any
other invocation which gets the same value from time().

 

[Keith Thompson]

On Wed, 21 Nov 2012 19:09:18 +0000, Adam Wysocki wrote: [...]

If it's worth going to that much trouble, it's probably worth using a
better random number generator than rand() (one provided by the
implementation but not specified by the C standard).

But that doesn't do anything about the lack of non-determinism (entropy).
A better PRNG may give you better random numbers, but without something
other than time(), they'll be exactly the same random numbers as any
other invocation which gets the same value from time().

Some PRNGs are self-seeding. For example, if you can read
data from /dev/random, you'll get numbers that are pretty much
cryptographically secure (and /dev/urandom is nearly as good and
much faster).

 

[Rosario1903]

K&R has one of the best indexes I have ever seen in a technical book.

yes

 

[Ben Bacarisse]

Maybe adding process ID to the seed calculation would do the job.

Instead of:

srand(time(NULL))

Use:

srand(time(NULL) ^ getpid())

Or even:

srand(time(NULL) ^ (getpid() << 16))

There a small thing you can do that might help on some (possibly
theoretical) systems:

srand(time(NULL) * 1000ULL);

It's largely harmless on most systems since all you normally want is
something that varies using the least significant bits of the time and
1000 times that is as good anything else, but on a system with a
floating point time_t you get more of the variation.

(The use of ULL is just to make it unlikely that the multiplication will
overflow in the case of a signed integer time_t.)

 

[Adam Wysocki]

If it's worth going to that much trouble, it's probably worth using
a better random number generator than rand() (one provided by the
implementation but not specified by the C standard).

It might work when the only goal is to have different random seed in
processes forked many times per second.

AW

 

[Adam Wysocki]

but on a system with a floating point time_t you get more of the
variation.

POSIX says that "time_t and clock_t shall be integer or real-floating
types", so it is possible, but can you give an example of such system?
I've never seen one.

AW

 

[Adam Wysocki]

Some PRNGs are self-seeding. For example, if you can read
data from /dev/random, you'll get numbers that are pretty much
cryptographically secure (and /dev/urandom is nearly as good and
much faster).

Remember that /dev/random can quickly run out of numbers when entropy
pool gets empty.

AW

 

[Ben Bacarisse]

POSIX says that "time_t and clock_t shall be integer or real-floating
types", so it is possible, but can you give an example of such system?

No, hence my "possibly theoretical" remark. Maybe it should have been
"probably theoretical". I see that there was a proposal to The Open
Group to amend the its standard (AKA POSIX) to rule out all floating
type for time_t. I don't know what happened to it -- I found the
document tracking system rather confusing.

I've never seen one.

Nor I.

 

[army1987]

[...]

The main issue is that time() appears to be about the only portable
source of non-determinism available, and it's typically rather weak.

Well, there's tmpnam()...

 

[Nick Keighley]

    So if I just wanted to print the date and time I would use strftime() ?

what does the man page for strftime say?

 

[Nick Keighley]

Given an application for which, the standard rand family of functions
is sufficient, why would one want to make consecutive invocations to
srand?

I ran into trouble once when I started several identical executables
at once. Thet all got the same "random" seed.

 

[Nick Keighley]

    Is that really that random? As long as a process has fork() 'ed and the
process is running it's pid isn't going to change is it until the system
kills it.btw to  stay on-topic here that caret and those << indicators.I've
never seen that in C except maybe headers. Are they preprocessing tokens?

good grief. RTFM!