Xref: utzoo comp.unix.sysv386:8307 comp.lang.c:39488 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!mtxinu!ed From: ed@mtxinu.COM (Ed Gould) Newsgroups: comp.unix.sysv386,comp.lang.c Subject: Re: time(0L) - history of a misconception Message-ID: <1991May22.153250.3192@mtxinu.COM> Date: 22 May 91 15:32:50 GMT References: <1991May14.040042.15199@jpradley.jpr.com> <588@sherpa.UUCP> <1141@mwtech.UUCP> <4138@uc.msc.umn.edu> Reply-To: ed@mtxinu.COM (Ed Gould) Organization: mt Xinu, Berkeley Lines: 41 >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@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."