On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ken Camann" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
