Xref: utzoo comp.unix.sysv386:8310 comp.lang.c:39490 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.unix.sysv386,comp.lang.c Subject: Re: time(0L) - I'm sorry, I can't resist Message-ID: <1991May23.040054.23555@Think.COM> Date: 23 May 91 04:00:54 GMT References: <381@tmcsys.UUCP> <1200@applix.com> Sender: news@Think.COM Reply-To: barmar@think.com Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article <1200@applix.com> scotte@applix.UUCP (Scott Evernden) writes: >Name for me any modern computer in any kind of common use which will >barf at: > time(0L); I frequently respond to this frequent question with one or two machines I'm familiar with, but I'm not going to do that this time. Suffice it to say that there *are* systems where the null pointer is not implemented as the same bit pattern as 0L. No, these systems are not "in common use". 90% of all C programs are probably running on 80*86, 680x0, VAX, and SPARC processors, but does that mean that all other systems should be ignored? Prototypes are the most appropriate solution to this problem. With a prototype in scope, the above call works right on any ANSI-conforming implementation. But if you need to be portable to pre-ANSI implementations, then is "(char *)0" so hard to write? Not only does it inform the compiler of the correct code to generate (in implementations that care), but it also makes the intent clearer to *human* readers of the code. What's the point of looking for a way around something that's so clearly right? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar