When compiling my cryptacular extension https://bitbucket.org/dholth/cryptacular I noticed -DPy_LIMITED_API -DPY_SSIZE_T_CLEAN creates a binary that does not actually use the limited api. This causes segfaults on Linux but does not appear to cause problems on Windows.

I found some emails suggestid PY_SSIZE_T_CLEAN was supposed to go away entirely?

First we should make PY_SSIZE_T_CLEAN mandatory for the term of at least two releases (or to the end of 2.7 support).

Here it is. https://mail.python.org/pipermail/python-3000/2008-November/015344.html

On Sat, Nov 22, 2008 at 06:29, Barry Warsaw <barry at python.org> wrote:
>
> On Nov 22, 2008, at 4:05 AM, Martin v. Löwis wrote:
>
>> I just noticed that the Python 3 C API still contains PY_SSIZE_T_CLEAN.
>>
>> This macro was a transition mechanism, to allow extensions to use
>> Py_ssize_t in PyArg_ParseTuple, while allowing other module continue
>> to use int.
>>
>> In Python 3, I would like the mechanism, making Py_ssize_t the only
>> valid data type for size in, say, s# parsers.
>>
>> Is it ok to still change that?
>
> Given that we just released the last planned candidate, I'd say it was too
> late to change this for Python 3.0.
>

But we can at least document that the macro is a gone as soon as 3.0
final is out the door.

-Brett

Oh, I can avoid this problem by setting Py_LIMITED_API to 0x30300000 or greater.

> Oh, I can avoid this problem by setting Py_LIMITED_API to 0x30300000 or greater.

Hum, maybe the behavior is different because of the following code in Include/modsupport.h:

/* Due to a glitch in 3.2, the _SizeT versions weren't exported from the DLL. */
#if !defined(PY_SSIZE_T_CLEAN) || !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x03030000

See also bpo-40943: PEP 353: Drop support for PyArg_ParseTuple() format when PY_SSIZE_T_CLEAN is not defined.