time(0L) - I'm sorry, I can't resist

[j chapman flack]

In article <1991May23.040054.23555 at Think.COM> barmar at 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 at art-sy.detroit.mi.us                                    -MIKHS 0EODWPAKHS

Nothing I say represents Appropriate Roles for Technology unless I say it does.