Re: ssize_t vs win64
От | Peter Eisentraut |
---|---|
Тема | Re: ssize_t vs win64 |
Дата | |
Msg-id | 1262479106.3542.6.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | Re: ssize_t vs win64 (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: