Xref: utzoo comp.unix.sysv386:8650 comp.lang.c:39776 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!malgudi!caen!math.lsa.umich.edu!sharkey!fmsrl7!art-sy!news From: chap@art-sy.detroit.mi.us (j chapman flack) Newsgroups: comp.unix.sysv386,comp.lang.c Subject: Re: time(0L) - I'm sorry, I can't resist Message-ID: <9106011048.aa06266@art-sy.detroit.mi.us> Date: 1 Jun 91 14:48:37 GMT References: <381@tmcsys.UUCP> <1200@applix.com> <1991May23.040054.23555@Think.COM> Reply-To: chap@art-sy.detroit.mi.us (j chapman flack) Organization: Appropriate Roles for Technology Lines: 33 In article <1991May23.040054.23555@Think.COM> barmar@think.com writes: >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 Mr. Margolin implies that time(0L) is not a problem on the 80*86. For x > 2, the 80x86 supports two flavors of pointer (near and far) and two sizes of offset (16 and 32 bit). The combinations are: near, 16: sizeof(*long) != sizeof(long) far, 16: sizeof(*long) == sizeof(long) BUT null value not all-zero in the implementations I know of far, 32: sizeof(*long) != sizeof(long) near, 32: sizeof(*long) == sizeof(long) and null value COULD be all-zero if the compiler implementor felt like it. So time(0L) *is* incorrect in (at least) 3 out of 4 cases on an 80x86, x > 2. It's incorrect in *all* cases on earlier 80x86's (though I could imagine an implementation that used 0x0000:0x0000 as the null pointer; the ones I know of all use segment:0x0000.) Of course all my sizeof() comparisons above are based on a 32-bit long, which is yet another assumption.... I replied to Mr. Evernden by mail before I saw this article. Sorry for the duplication. -- Chap Flack Their tanks will rust. Our songs will last. chap@art-sy.detroit.mi.us -MIKHS 0EODWPAKHS Nothing I say represents Appropriate Roles for Technology unless I say it does.