time(0L) - history of a misconception (was Re: SCO password generator)

Chris Lewis clewis at ferret.ocunix.on.ca
Thu May 23 01:03:28 AEST 1991


In article <381 at tmcsys.UUCP> lh at aega84.UUCP (L. Hirschbiegel) writes:
>In article <1141 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>>In article <588 at sherpa.UUCP> rac at sherpa.UUCP (Roger Cornelius) writes:
>>[...]
>>>	long seed = time(0L);
>>	                 ^^--------- wrong
>>	           time((long *)0);
>>	                ^^^^^^^^^--- right

>Ever tried to RTFM for yourself? 

>	  DESCRIPTION
>	       The time	system call returns the	value of time in seconds
>	       since 00:00:00 Greenwich	Mean Time (GMT), January 1, 1970.

>	       If tloc is non-zero, the	return value is	also stored in the
>                   ^^^^^^^^^^^
>	       location	to which tloc points.

You omitted the part where it defined time as:

	long time (long *tloc)

(Or, for that matter, "time_t time (time_t *tloc);")

Within context, the "non-zero" really means "non-null pointer to long(time_t)"

[I've even seen manual pages where they are out-and-out wrong.  I've
seen time(0) in some manual pages, and that won't work either]

>If you still don't understand: I'll help you! 
>For this little test program:

Lothar goes on to "prove" his point by test compiling a bit of C
and showing that "time(0L)" and "time((long *) 0)" compiles the same
way.  (on what looks like a 386 according to the assembler)

You're lucky.  Not all machines have pointers that are the same length
as longs.  Try this code on a PDP-11 or on many small mode 8086 compilers:

int func(a, b, c)
long *b; int a,c; {
	printf("%d:%d\n", a, c);
}

func(4, 0L, 4);

It won't print "4:4".  Some compilers will print "4:0", and some'll print "0:4",
and some will print garbage.

func(4, (long*)0, 4) will print 4:4.

Lint and Martin are correct.  Pointers aren't longs.  They ain't ints
either.

Didn't your math teacher tell you that you can't prove a theory on a single
example?  On the other hand, any theory can be disproved by a single
counter-example.
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!



More information about the Comp.unix.sysv386 mailing list