Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!spool.mu.edu!uunet!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: time(0L)
Message-ID: <330@nazgul.UUCP>
Date: 24 May 91 20:12:44 GMT
References: <1991May14.040042.15199@jpradley.jpr.com> <588@sherpa.UUCP> <1141@mwtech.UUCP> <4138@uc.msc.umn.edu>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 15

In article <4138@uc.msc.umn.edu> jeff@uf.UUCP (Jeff Turner) writes:
/Perhaps you are confusing time(0) with time(0L).  Calling time(0) on a 16-bit
/machine (e.g. PCs not running 386 UNIX) will push only a 16 bit value onto the
/stack instead of the 32 bit address that time() is expecting (and is going to
/use).  Since half of the 32-bit address will have a random (and probably
/non-zero) value, time() will use it as an address to store the current time
/into, and bash your memory or cause range-error core-dump.

Actually, in all the 16 bit compilers I'm currently familiar with,
time() is prototyped such that the argument is correctly cast, and the
problem doesn't arise. For instance, time(long *) being the prototype,
time(0) becomes time((long*)0) which will always work correctly.

The time you unavoidably get into trouble is if it is a varargs function
like printf().