time(0L) - history of a misconception

[Ed Gould]

>You are right -- to ensure portability, you should always pass what is expected
>(i.e. a pointer and not a long).  This way, if someday a machine is created 
>on which a pointer to a long is a different size then a long, the program will
>still work.  However, I don't know of any machines on which the two differ.

The machine on which this stuff was first developed - the PDP-11 - is
one.  It has 16-bit pointers.  So does any machine with a 64K address
space.  In fact, the early (Sixth Edition and before) form of the time()
call was

	time(t)
	int t[2];

In those days, "long" ints were represented explicitly as arrays
of two ints.  The time() function took (a pointer to) one of those.
It had no meaningful return value.

In Seventh Edition UNIX, by which time the C language had been
extended to include longs and typedefs, time() became

	time_t time(t)
	time_t *t;

Not too long ago, I saw a piece of code (in a large, now commercial,
software system that will remain nameless) that looked like this:

		time_t now;
	#if some_machine_type || some_other_machine_type
		now = time(0);
	#else
		now = time();
	#endif

Evidently, time() failed on those machines when passed no arguments,
so somebody "fixed" the bug.  I wish people would take the 15 or 20
seconds it takes to get something like this right.
-- 
Ed Gould			No longer formally affiliated with,
ed at mtxinu.COM			and certainly not speaking for, mt Xinu.

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."