Re: A Windows x64 ****t of PostgreSQL

"Ken Camann" <kjcamann@[EMAIL PROTECTED]
> writes:
> Well actually, let me be as strict as possible because I don't know
> the latest C standards very well (I am a C++ programmer).  Am I
> correct that the standard says that sizeof(size_t) must be
> sizeof(void*), and that no compiler has ever said otherwise?

I'm not sure that the spec actually requires that in so many words,
but it's hard to imagine a sane implementation where it isn't true.
(Now, I've worked on some less-than-sane hardware, but that stuff
all died the real death in the eighties or so.  Flat memory models
have been the only kind anyone would tolerate for a long time now.)

> 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 sup****ts, 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 sup****t that?

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

			regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers