This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dcoles
Recipients dcoles, pitrou, vstinner
Date 2011-05-06.19:12:48
SpamBayes Score 2.232059e-09
Marked as misclassified No
Message-id <1304709169.2.0.592458854747.issue12010@psf.upfronthosting.co.za>
In-reply-to
Content
After doing some more investigation it appears that Android's wchar_t support before android-9 is totally broken (see http://android.git.kernel.org/?p=platform/ndk.git;a=blob_plain;f=docs/STANDALONE-TOOLCHAIN.html;hb=HEAD). With android-9 you get 4 byte wchar_t and working wide character functions.

Possibly of more interest for Python is that it's no longer buildable without wchar_t support. While unicodeobject is pretty good at checking HAVE_WCHAR_H, a number of modules and even pythonrun.c directly use wchar_t or functions like PyUnicode_FromWideChar without providing a fallback. Does Python 3 now require wchar_t or are these bugs? (either option seems sensible).

A few other notes:
HAVE_USABLE_WCHAR_T looks like it was a check for unsigned/>16 bits wchar_t that would allow them to be directly memcpy'd. The code in unicodeobject.c seems not to really use this anymore except (it's happy with signed or unsigned) and it looks like the check is only used for Windows now.

To properly support wchar_t of size 1 you would basically implement multibyte character storage either with UTF-8 or just packing two wchar_t's with UTF-16. At least in Android the distinction doesn't seem to matter as Android's internationalziation/localization policy seems to be "use Java".
History
Date User Action Args
2011-05-06 19:12:49dcolessetrecipients: + dcoles, pitrou, vstinner
2011-05-06 19:12:49dcolessetmessageid: <1304709169.2.0.592458854747.issue12010@psf.upfronthosting.co.za>
2011-05-06 19:12:48dcoleslinkissue12010 messages
2011-05-06 19:12:48dcolescreate