Xref: utzoo comp.unix.sysv386:8345 comp.lang.c:39517
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!sumax!polari!6sigma2
From: 6sigma2@polari.UUCP (Brian Matthews)
Newsgroups: comp.unix.sysv386,comp.lang.c
Subject: Re: time(0L) - history of a misconception
Message-ID: <4188@polari.UUCP>
Date: 23 May 91 16:28:19 GMT
References: <588@sherpa.UUCP> <1141@mwtech.UUCP> <381@tmcsys.UUCP>
Organization: Seattle Online Public Unix (206) 328-4944
Lines: 38

In article <381@tmcsys.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes:
|In article <1141@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
|>In article <588@sherpa.UUCP> rac@sherpa.UUCP (Roger Cornelius) writes:
|>[...]
|>>	long seed = time(0L);
|>	                 ^^--------- wrong
|>	           time((long *)0);
|>	                ^^^^^^^^^--- right
|Ever tried to RTFM for yourself? 
|
|	  NAME
|	       time - get time
|	       If tloc is non-zero, the	return value is	also stored in the
|                   ^^^^^^^^^^^
|	       location	to which tloc points.

You'll get yourself in trouble by taking parts of TFM out of context.
The part you left out reads something like:

	long time ((long *) 0)
	long time (tloc)
	long *tloc;

Tloc still has to be of the correct type, whether zero or non-zero.  This
can happen by having a prototype in scope or with an appropriate cast.

|If you still don't understand: I'll help you! 
|For this little test program:
|[program calling time with (incorrect) 0L and (correct) (long *)0]

This just proves that on your particular OS at some particular release
level and version with some particular version of gcc, it happens to
work.  In general, portable code must assume time(0L) won't work.

|Repeat after me: IT DOESN'T MATTER :-)

Please remind me never to use any code you've written.  It will
undoubtedly fail in many strange and mysterious (to you at least) ways.