msg132558 - (view) |
Author: Wolfgang Rohdewald (wrohdewald) |
Date: 2011-03-30 00:11 |
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 |
|
|
msg132569 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2011-03-30 05:41 |
Where does R:\include\msvc\sys/types.h come from? |
|
|
msg132571 - (view) |
Author: Wolfgang Rohdewald (wrohdewald) |
Date: 2011-03-30 06:50 |
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 |
|
|
msg132574 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2011-03-30 07:44 |
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. |
|
|
msg132788 - (view) |
Author: Mark Hammond (mhammond) *  |
Date: 2011-04-02 06:52 |
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) |
|
|
msg220652 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-15 17:11 |
Is the patch acceptable? |
|
|
msg236093 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2015-02-16 06:54 |
Can we have a formal patch review please? |
|
|
msg236207 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2015-02-19 02:09 |
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. |
|
|
msg387854 - (view) |
Author: Pablo Galindo Salgado (pablogsal) *  |
Date: 2021-03-01 11:18 |
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 |
|
|