homepage

compiling pykde on windows with msvc2010 on a 32bit Windows 7:
sipdnssdpart0.cpp
R:\include\msvc\sys/types.h(52) : error C2371: 'ssize_t' : redefinition; different basic types
 c:\python27\include\pyconfig.h(201) : see declaration of 'ssize_t'
I can fix this by defining ssize_t as long in pyconfig.h or 
as int in kdewin/include/msvc/sys/types.h
the original files from windows define SSIZE_T as long so to
me this seems like a bug in pyconfig.h, it should say
typedef _W64 long ssize_t
Python27\include\pyconfig.h says (same in Python32):
#ifdef MS_WIN64
typedef __int64 ssize_t;
#else
typedef _W64 int ssize_t;
#endif
while kdewin/include/msvc/sys/types.h says:
typedef SSIZE_T ssize_t;
SSIZE_T is defined in Microsoft SDKs/Windows/v7.0A/Include/BaseTsd.h:
typedef LONG_PTR SSIZE_T, *PSSIZE_T;
and LONG_PTR from same directory, intsafe.h:
#if (__midl > 501)
typedef [public] __int3264 LONG_PTR;
#else
#ifdef _WIN64
typedef __int64 LONG_PTR;
#else
typedef _W64 long LONG_PTR;
#endif // WIN64
#endif // (__midl > 501)
for __midl see
http://msdn.microsoft.com/en-us/library/aa367301(v=vs.85).aspx 

Where does R:\include\msvc\sys/types.h come from?

types.h is from kdewin/include/msvc/sys
git clone git://anongit.kde.org/kdewin
types.h uses SSIZE_T but that is nowhere defined in KDE, so it must be the original one from msvc

Should Python.h systematically avoid defining symbols without a Py prefix?
See attached patch, which defines Py_ssize_t in pyconfig.h.
The same can be said for other symbols defined there: pid_t, copysign, hypot.

As Tim Roberts says on the python-win32 list:
> Actually, on closer examination, it may be a bit difficult to sell this. The Microsoft compilers do not define this symbol at all. The SDK defines SSIZE_T (as a long). Nothing defines ssize_t. 
http://code.activestate.com/lists/python-win32/11231/ for the full post.
So yeah, the conclusion is that we shouldn't define such symbols incase someone else does too. So conceptually I'm +1 on that patch (I'm yet to try it and probably will not get a chance for a week or 2)

Is the patch acceptable?

Can we have a formal patch review please?

Patch needs updating, and I'd expect pyport.h to start by checking if HAVE_PY_SSIZE_T is defined. Otherwise, we may try to re-typedef Py_ssize_t.

New changeset c994ffe69553cbb34f1cea6a4494d6e7657f41b0 by Jozef Grajciar in branch 'master':
bpo-11717: fix ssize_t redefinition error when targeting 32bit Windows app (GH-24479)
https://github.com/python/cpython/commit/c994ffe69553cbb34f1cea6a4494d6e7657f41b0