Daniel Stutzbach wrote:
> 
> Daniel Stutzbach <daniel@stutzbachenterprises.com> added the comment:
> 
> On Sat, May 8, 2010 at 11:35 AM, Marc-Andre Lemburg
> <report@bugs.python.org> wrote:
>> One of the more important cases you are missing is the
>> argument parser in Python:
> 
> Thanks.  I've had my head buried in c-api/unicode.html and unicodeobject.h.
> 
>> Py_UNICODE *x;
>> Py_ssize_t y;
>> PyArg_ParseTuple(args, "u#", &x, &y);
> 
> My plan is to not define Py_UNICODE in Unicode-agnostic mode, to
> prevent that from compiling.
>

And later...

undefined, I wonder if it would be sufficient to declare Py_UNICODE like this:
>
> struct PY_UNICODE_TYPE;
> typedef struct PY_UNICODE_TYPE Py_UNICODE;
>
> That would allow extensions to pass opaque Py_UNICODE pointers around, but not allow them to
dereference the pointers nor evaluate sizeof(Py_UNICODE).
>
> That would make PyUnicodeObject safe, as well as PyUnicode_Encode* and several other functions
(anything that doesn't manipulate individual characters, basically).

Please make sure that these compiler tricks are portable
enough across the supported Python platforms. Just checking
with GCC 4.3 is not good enough.

I suppose you could use the buildbots to gather information
on how different compilers behave (e.g. by checking in a patch,
letting the buildbots run and then reverting it, if there's
a problem). I'm just not sure how you could check for optimization
compiler bugs/features using the buildbots.