Re: A Windows x64 port of PostgreSQL

kjcamann(at)gmail(dot)com ("Ken Camann") writes:
> On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Ken Camann" <kjcamann(at)gmail(dot)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.

AFAIK, we oughtn't care what C++ standards say, because PostgreSQL is
implemented in C, and therefore needs to follow what the *C* standards
say.

> 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?

#include <stdio.h>

int main (int argc, char **argv) {
int i;
long j;
long long k;
printf ("size of int: %d\n", sizeof(i));
printf ("size of long: %d\n", sizeof(j));
printf ("size of long long: %d\n", sizeof(k));
}

Output on 32 bit Linux:
size of int: 4
size of long: 4
size of long long: 8

Output on 64 bit Linux:
size of int: 4
size of long: 8
size of long long: 8
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxfinances.info/info/
"The real romance is out ahead and yet to come. The computer
revolution hasn't started yet. Don't be misled by the enormous flow of
money into bad defacto standards for unsophisticated buyers using poor
adaptations of incomplete ideas." -- Alan Kay