<div class="gmail_quote">On Mon, Nov 2, 2009 at 11:57 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We'd also have to hide the macros that can be used to access the<br>
internals of a PyUnicodeObject, in order for that approach to be safe.<br>
Basically, an extension would have to include a second header file to<br>
use those macros and it would have to somehow indicate to the linker<br>
that it is using UCS2 or UCS4 internals as well.<br></blockquote><div><br>I don't know of a portable way to indicate that to the linker simply by including a header file.  I wish I did.<br><br>Here is one idea that will cause a linker error if there's a mismatch and one of the macros are used.  It does cause the macro to execute an extra CPU instruction or two, though.  <br>
<br>In unicodeobject.h:<br><br>/* Require the macro to reference a global variable that will only be
present if the Unicode ABI matches correctly.  Arrange for the global
variable to always have the value zero, and add it to the return value
of the macro. */<br><br>#if Py_UNICODE_SIZE == 4<br>extern const int Py_UnicodeZero_UCS4;<br>#define Py_UNICODE_ZERO (Py_UnicodeZero_UCS4)<br>#else<br>extern const int Py_UnicodeZero_UCS2;<br>#define Py_UNICODE_ZERO (Py_UnicodeZero_UCS2)<br>

#endif<br>
<br>#define PyUnicode_AS_UNICODE(op) \ <br>        (Py_UNICODE_ZERO + (((PyUnicodeObject *)(op))->str))<br><br>In unicodeobject.c:<br><br>
extern const int Py_UNICODE_ZERO = 0;<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would want to err on the safe side here -- if it was at all easy to<br>
create an extension that *seems* to be ABI-neutral but *actually*<br>
relies on knowledge about the UCS2 or UCS4 representation, we'd be<br>
creating a worse problem. Users don't like stuff not working, but they<br>
*really* don't like stuff crashing with random core dumps -- if it has<br>
to be broken, let it break very loudly and explicitly. The current<br>
approach satisfies that requirement -- it probably just errs too far<br>
on the "never assume it might work" side.<br></blockquote><div><br>Agreed. <br></div></div><blockquote style="margin: 1.5em 0pt;">--<br>
Daniel Stutzbach, Ph.D.<br>
President, <a href="http://stutzbachenterprises.com">Stutzbach Enterprises, LLC</a>
</blockquote>