Re: A Windows x64 port of PostgreSQL - Mailing list pgsql-hackers

On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Ken Camann" <kjcamann@gmail.com> writes:
>> EMT64/AMD64 is new compared to the older architectures, I
>> would guess the older ones predate the time when it became a somewhat
>> de facto standard to leave "long int" at 4 bytes, and make "long long"
>> the new 64-bit type.
>
> Apparently your definition of "de facto standard" is "any idiotic
> decision Microsoft cares to make".  AFAIK there is *no* system other
> than WIN64 where long is narrower than size_t; and I rather doubt that
> there ever will be any.  "long long" is generally understood to mean
> a type that the hardware supports, but not very efficiently (ie, it's
> double the native word width) --- and one would hope that pointers
> are not in that category.  On a 64-bit machine LL really ought to
> denote 128-bit arithmetic ... I wonder what curious syntax Microsoft
> will invent when they realize their compilers ought to support that?

Actually, it isn't my definition.  I haven't really worked with enough
compilers to make a claim like that, I got that impression (and the
phrase "de facto") from the proceedings of the C++0x standards
committee where they finalized long long as being required to be 8
bytes.  I think it ultimately does come from Microsoft/Intel, because
they did follow the old width convention in the 16 bit days, that is
sizeof(int) was 2 (word width) and sizeof(long) was 4.

When 32-bit arrived (much too late, at Microsoft) most x86 compilers
that had formerly used the segmented memory model made int 4 bytes
like people felt "it was supposed to be" but left long at 4 the way it
was so as not to bloat all the variables to double words on such a
register-poor architecture as x86.  I actually think of Borland Turbo
C++ and Intel more than Microsoft when I think of this decision.  For
that reason, I would have thought you would see the same thing on all
x86 systems...but now I realize that's stupid.  Once you leave Windows
its a gcc world, so it would be the way it always should have been, on
every POSIX system.  Even then though, if I were to use Linux on x64,
wouldn't sizeof(int) be 4 and not 8?

I bring this up for more reasons than spamming the list with trivia,
it leads to a very important question:

> Anyway, back to the immediate problem.  What would probably make sense
> to try as a first step is something like
>
> #ifndef WIN64
> typedef unsigned long Datum;    /* XXX sizeof(long) >= sizeof(void *) */
> #else
> typedef unsigned long long Datum;       /* Microsoft's out in left field */
> #endif
>
> and see how many warnings that eliminates ...

It's a question about style.  If Microsoft Visual C really is the only
one like this, then I guess there is no harm in #ifdef _WIN64 instead
of #ifdef (some other name that captures the peculiarity of what is
happening but isn't MSFT dependent).  win32.h (not written by me)
already defines SIZEOF_SIZE_T and SIZEOF_LONG_INT (or something like
that)...It might be a better idea to use those two.

But the thing is, this isn't the only issue.  There is the fact that
"int" appears in c.h for memory offsets and not long.  As long as I
might have to change a whole lot of this stuff to make exceptions for
windows, I was wondering what the community thinks of the way this is
all currently handled and what advice they have might have for me when
changing stuff.  There seems to be two problems that affect 64-bit
POSIX systems too:

1. An object in memory can have size "Size" (= size_t).  So its big
(maybe 8 bytes).
2. An index into the buffer containing that object has index "Index"
(= int)  So its smaller (maybe 4 bytes).  Now you can't index your big
object, unless sizeof(size_t) = sizeof(int).  But sizeof(size_t) must
be at least 8 bytes on just about any 64-bit system.  And sizeof(int)
is still 4 most of the time, right?

But I am thinking that if I knew more about postgres, maybe I would
realize something important, like the way that it works ensures that
Offset is never greater than a certain amount, because (for example, I
have no idea if this is true or not) maybe its only used to point
inside a disk block or something.  Who would know this?

-Ken