"Ken Camann" <kjcamann@gmail.com> 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 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?
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
