chris wrote:
C++0x standards
committee where they finalized long long as being required to be 8
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.
I agree the C++ standards should matter one bit
On Thu, Jul 03, 2008 at 01:45:06AM -0400, Ken Camann wrote:
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
[EMAIL PROTECTED] (Ken Camann) writes:
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
A bit long - the summary is that intptr_t should probably be used,
assuming I understand the problem this thread is talking about:
Ken Camann wrote:
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
Am Donnerstag, 3. Juli 2008 schrieb Ken Camann:
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
Peter Eisentraut [EMAIL PROTECTED] writes:
Present us the actual problems as you discover them, and we will find a
solution. Right now we are just guessing.
There seems to be two problems that affect 64-bit POSIX systems too:
Well, 64-bit POSIX works just fine, so unless you can present an
Tom Lane wrote:
To get a working WIN64 port it'd be necessary to go around and replace
long with size_t/ssize_t in the places where it matters --- but there
are not 450 of them, I don't think. And I'd advise not touching the
places that use int; that will just bloat the patch and make it harder
Ken Camann napsal(a):
Hello everyone,
I don't really know much about contributing to projects, mailing
lists, or really anything that has to do with the UNIX culture (I am
not a UNIX fan). So forgive my ignorance of how this is supposed to
work.
I think you meant PostgreSQL not MySQL in the
On Wed, Jul 2, 2008 at 9:09 AM, Bernd Helmle [EMAIL PROTECTED] wrote:
--On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann [EMAIL PROTECTED]
wrote:
I assume it would only really matter if you did this to
a pointer, and perhaps that is happening somewhere (but I doubt it
since postgres
On Wed, Jul 2, 2008 at 8:32 PM, Ken Camann [EMAIL PROTECTED] wrote:
I'd really like to help out with this, but I'm not sure I can work on
a patch even if I change these things for myself. Fixing this code
would touch a lot of important internals in postgres (albeit in a
small way), so my
Ken Camann [EMAIL PROTECTED] writes:
Oh I see. Between this and looking again at the warning list, I see
that it will probably take a lot more work than I thought. There are
about 450 occurrences of the assumption that sizeof(size_t) ==
sizeof(int).
[ blink... ] There are *zero*
On Wed, Jul 2, 2008 at 8:43 PM, Tom Lane [EMAIL PROTECTED] wrote:
Ken Camann [EMAIL PROTECTED] writes:
Oh I see. Between this and looking again at the warning list, I see
that it will probably take a lot more work than I thought. There are
about 450 occurrences of the assumption that
Ken Camann [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
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
14 matches
Mail list logo
