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

[Sean Eric Fagan]

In article <9106011048.aa06266 at art-sy.detroit.mi.us> chap at art-sy.detroit.mi.us (j chapman flack) writes:
>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:

Uhm, better go back and reread your manual.  For 808[86] and 80?8[86], there
are two flavours of pointers:  16-bit ("near"), and 32-bit (actually 20 bit
on the '286 and previous), aka "far" in some compilers.

>So time(0L) *is* incorrect in (at least) 3 out of 4 cases on an 80x86, x > 2.

But it won't cause things to fail, except in some very limited cases
(basicly, where one more 16-bit word will cause a stack fault).

>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.)

Actually, most use segment 0, offset 0, since most people like being able to
use address 0 of an array (yes, the compiler could fudge things, most don't,
though).

>Of course all my sizeof() comparisons above are based on a 32-bit long, which
>is yet another assumption....

long's are guaranteed to be at least 32 bits, as per ANSI C.  Since most
(all?) popular compilers for the iAPX86 architecture (and descendents, of
course) at least claim some measure of ANSI conformance, and 32 bits is
really the only feasible size of a long (other than 16, which defeats the
purpose of a long), you can pretty much rest assured that a long is 32 bits
on an Intel *86 system.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef at kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.