Marc-Andre Lemburg <m...@egenix.com> added the comment: Daniel Stutzbach wrote: > > Daniel Stutzbach <dan...@stutzbachenterprises.com> added the comment: > > On Sat, May 8, 2010 at 5:03 AM, Marc-Andre Lemburg > <rep...@bugs.python.org> wrote: >> If you can propose a different method of reliably protecting against >> mixed Unicode build module loads, that would be great. We could then >> get rid off the wrapping altogether. > > The following code will cause a link error 100% of the time iff > there's a mismatch: > > #ifndef Py_UNICODE_WIDE > #define _Py_Unicode_Build_Symbol _Py_UCS2_Build_Symbol > #else > #define _Py_Unicode_Build_Symbol _Py_UCS4_Build_Symbol > #endif > extern int _Py_Unicode_Build_Symbol; /* Defined in unicodeobject.c */ > static int *_Py_Unicode_Build_Symbol_Check = &_Py_Unicode_Build_Symbol; > > In practice, I'd surrounded it with a bunch #ifdefs to disable the > "defined but not used" warning in gcc and MSVC.
Are you sure this doesn't get optimized away in practice ? FWIW: I still like the import logic solution better, since that will make it possible for the user to see a truly useful error message rather than just some missing symbol linker error. >> Please note that UCS2 and UCS4 builds of Python are different in >> more ways than just the underlying Py_UNICODE type. E.g. UCS2 builds >> use surrogates when converting between Unicode and bytes which >> UCS4 don't, sys.maxunicode is different, range checks use different >> bounds, unichr() behaves differently, etc. etc. > > That's true, but those differences are visible from pure-Python code > as well aren't they? Sure, though, I don't see how this relates to C code relying on these details, e.g. a C extension will probably use different conversion code depending on whether UCS2 or UCS4 is compatible with some external library, etc. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8654> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
