ssize_t vs win64
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef __int64 ssize_t;
The postgresql deifnition comes from include/port/win32.h, which leads
me to think that we should just change that one to be int64? (it
builds and passes tests if I do)
I'm not entirely sure what the type is for, though, so I figured I'd
better ask :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;
What file/line is that? I don't see that in my copies.
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;What file/line is that? I don't see that in my copies.
You mean in python? It's in pyconfig.h, line 205 (the version
manually maintained for non-autoconf platforms). The version I have
is:
Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit
(AMD64)] on win32
(latest on their website as of a couple of days ago)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
I'm not entirely sure what the type is for, though,
It's supposed to be the same width as size_t but signed. I would assume
that it should be 64 bits on Win64.
According to SUS this type should be provided by sys/types.h:
http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
so I'm not clear why we have to provide it ourselves at all.
regards, tom lane
On Sat, Jan 2, 2010 at 16:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
I'm not entirely sure what the type is for, though,
It's supposed to be the same width as size_t but signed. I would assume
that it should be 64 bits on Win64.
Yeah, seems reasonable. I'll put in that #ifdef in win32.h then.
According to SUS this type should be provided by sys/types.h:
http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
so I'm not clear why we have to provide it ourselves at all.
Should, but it's not included in types.h in the Microsoft SDK:s. It
seems to have time_t and off_t, but that's about it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;What file/line is that? I don't see that in my copies.
You mean in python? It's in pyconfig.h, line 205 (the version
manually maintained for non-autoconf platforms). The version I have
is:
Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit
(AMD64)] on win32
Seems kind of buggy. They shouldn't be defining it at all.
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;What file/line is that? I don't see that in my copies.
You mean in python? It's in pyconfig.h, line 205 (the version
manually maintained for non-autoconf platforms). The version I have
is:
Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit
(AMD64)] on win32Seems kind of buggy. They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut <peter_e@gmx.net> wrote:
Seems kind of buggy. �They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
What's buggy is M$ failing to provide it in their <sys/types.h> header.
It's unlikely they'll pay any attention to our opinions, however.
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut <peter_e@gmx.net> wrote:
Seems kind of buggy. ���They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
What's buggy is M$ failing to provide it in their <sys/types.h> header.
It's unlikely they'll pay any attention to our opinions, however.I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.
What exactly do you think we might do differently? There is only one
sane definition for ssize_t on a 64-bit platform.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.What exactly do you think we might do differently? There is only one
sane definition for ssize_t on a 64-bit platform.
Well, I saw two definitions listed in this thread, and it wasn't clear
to me the Python one was known to be the correct one:
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef __int64 ssize_t;
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Well, I saw two definitions listed in this thread, and it wasn't clear
to me the Python one was known to be the correct one:
PostgreSQL has it as
typedef long ssize_t;
That one is our 32-bit-only definition.
regards, tom lane
On Sun, Jan 3, 2010 at 01:01, Bruce Momjian <bruce@momjian.us> wrote:
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.What exactly do you think we might do differently? There is only one
sane definition for ssize_t on a 64-bit platform.Well, I saw two definitions listed in this thread, and it wasn't clear
to me the Python one was known to be the correct one:PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;
You're missing the crucial point: That is that PostgreSQL uses long on
*32-bit*. Python uses __int64 on *64-bit*. PostgreSQL didn't *have* a
definition on 64-bit, so we fell back on the 32-bit one.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander wrote:
On Sun, Jan 3, 2010 at 01:01, Bruce Momjian <bruce@momjian.us> wrote:
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.What exactly do you think we might do differently? ?There is only one
sane definition for ssize_t on a 64-bit platform.Well, I saw two definitions listed in this thread, and it wasn't clear
to me the Python one was known to be the correct one:? ? ? ?PostgreSQL has it as
? ? ? ?typedef long ssize_t;? ? ? ?And python has it as:
? ? ? ?typedef __int64 ssize_t;You're missing the crucial point: That is that PostgreSQL uses long on
*32-bit*. Python uses __int64 on *64-bit*. PostgreSQL didn't *have* a
definition on 64-bit, so we fell back on the 32-bit one.
OK, so my question is whether __int64 is the right definition or only
what Python chose.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
OK, so my question is whether __int64 is the right definition or only
what Python chose.
I see no reason to question either the width or the signedness.
If you do, feel free to research away.
regards, tom lane
On sön, 2010-01-03 at 00:24 +0100, Magnus Hagander wrote:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut <peter_e@gmx.net> wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.PostgreSQL has it as
typedef long ssize_t;And python has it as:
typedef __int64 ssize_t;What file/line is that? I don't see that in my copies.
You mean in python? It's in pyconfig.h, line 205 (the version
manually maintained for non-autoconf platforms). The version I have
is:
Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit
(AMD64)] on win32Seems kind of buggy. They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
Python only uses ssize_t to define Py_ssize_t, and they could do that
without exposing their own definition of ssize_t if it's missing. But
as long as these hacks are constrained to one platform, it might not be
worth worrying about.