Thread: 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 HaganderMe: 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 HaganderMe: 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 HaganderMe: 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 win32 > > 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? -- Magnus HaganderMe: 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 astypedef 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 HaganderMe: 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 win32 > > > > 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? 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.