Xref: utzoo comp.unix.sysv386:8323 comp.lang.c:39497
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!wuarchive!uunet!mcsun!ukc!inmos!conor@lion.inmos.co.uk
From: conor@lion.inmos.co.uk (Conor O'Neill)
Newsgroups: comp.unix.sysv386,comp.lang.c
Subject: Re: time(0L) - history of a misconception (was Re: SCO password generator)
Message-ID: <16221@ganymede.inmos.co.uk>
Date: 23 May 91 09:27:10 GMT
References: <1991May14.040042.15199@jpradley.jpr.com> <588@sherpa.UUCP> <1141@mwtech.UUCP> <4138@uc.msc.umn.edu>
Sender: news@inmos.co.uk
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Lines: 15

In article <4138@uc.msc.umn.edu> jeff@uf.UUCP (Jeff Turner) writes:
>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.

Think of a 16-bit machine, where pointers are 16-bits, but longs are 32-bits.
Not a particularly obscure possibility.

(Oh - by the way - we sell one - the IMS T222 transputer).

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".