Casts for srand? (FAQ 13.17)

[Mara Guida]

"Each time I run my program, I get the same sequence of numbers back
from rand()."
The answer to question 13.17, in the c-faq is:

#include <stdlib.h>
#include <time.h>

srand((unsigned int)time((time_ t *)NULL));
Are all those casts in the srand() call really needed?
Is this ok, instead, relying on implicit casts when needed?

#include <stdlib.h>
#include <time.h>

srand(time(NULL ));
/* or even
srand(time(0));
*/
PS: According to the standard, does <stdlib.h#defin e NULL?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Tue, 08 Jan 2008 12:08:44 -0800, Mara Guida wrote:

"Each time I run my program, I get the same sequence of numbers back
from rand()."

The answer to question 13.17, in the c-faq is:

#include <stdlib.h>
#include <time.h>

srand((unsigned int)time((time_ t *)NULL));

Are all those casts in the srand() call really needed? Is this ok,
instead, relying on implicit casts when needed?

A cast is an explicit conversion. An implicit cast would be an implicit
explicit conversion.

But no, there's nothing wrong with relying on the implicit conversion
from 0 or NULL to time_t *, and from time_t to unsigned int. Depending on
the implementation, the casts may affect some diagnostics, but no bugs
will be introduced or fixed by them.

PS: According to the standard, does <stdlib.h#defin e NULL?

Yes. NULL is defined by <stddef.h>, <stdio.h>, <stdlib.h>, <string.h>,
<time.h>, <wchar.h>, and <locale.h>. It's harder to include standard
headers and _not_ get NULL defined, than it is to accidentally leave it
undefined.

[dj3vande]

In article <9d************ *************** *******@r60g200 0hsc.googlegrou ps.com>,
Mara Guida <ma*******@gmai l.comwrote:

>"Each time I run my program, I get the same sequence of numbers back
from rand()."

The answer to question 13.17, in the c-faq is:

#include <stdlib.h>
#include <time.h>

srand((unsigne d int)time((time_ t *)NULL));

Are all those casts in the srand() call really needed?

No. They're probably there for historical reasons.

>Is this ok, instead, relying on implicit casts when needed?

There's no such thing as an "implicit cast"; a cast is a source code
construct (and therefore inherently explicit) that forces a
conversion.
That nitpick aside, assuming you meant "implicit conversion", the
answer to your question is yes, it's perfectly valid.

>#include <stdlib.h>
#include <time.h>

srand(time(NUL L));
/* or even
srand(time(0)) ;
*/

If you forgot to #include <time.h>, you won't have a prototype in scope
for time(), and these would pass an integer 0 (or possibly a null void *)
instead of a null time_t *. Pre-ANSI C would have required a cast here
to force the right type to be passed, but now that we have prototypes
(and have for almost two decades) the correct solution is to
#include <time.hand let the compiler do the conversion for you.

Casting the return value is slightly less useless, but only slightly;
time_t (which time() returns) is required to be an arithmetic type, and
every arithmetic type can be converted to unsigned without a cast, but
your compiler might warn about some of them and the cast will tell it
to be quiet (which is in general not such a good idea, but is probably
valid here).
dave