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