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 to
[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
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 a
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
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 pres
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 l
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 inde
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,
"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
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
"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* occ
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
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
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 s
14 matches
Mail list logo
