Issue 1005113: test__locale fails on MacOS X (original) (raw)

Created on 2004-08-07 13:23 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (11)
msg21984 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-07 13:23
test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include <locale.h> #include <stdio.h> int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks....
msg21985 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-07 15:10
Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835)
msg21986 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-07 19:14
Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight!
msg21987 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-12 19:40
Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted?
msg21988 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-12 22:19
Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around.
msg21989 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-12 22:32
Logged In: YES user_id=357491 I just talked to a friend of mine and it looks like the function is gone from Tiger so this might not be a problem in the future. Plus, I don't know if we should be trying to work around this. Perhaps we should try to do this the proper way using CF for locale support? Don't know. At worst we should at least raise an exception for setlocale() . This is getting OS X specific enough to need input from Jack, so assigning to him.
msg21990 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-13 05:43
Logged In: YES user_id=580910 According to Bob the "feature" is present in the Tiger DP. I haven't checked this myself yet. I also haven't check older versions of the OS.
msg21991 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-13 17:38
Logged In: YES user_id=357491 They must have removed it between the Tiger test release and now since my friend has checkin rights on that part of the tree at Apple. Regardless, I am leaning towards having setlocale() raise an exception under OS X until we can possibly wrap CF stuff since __setonlyClocaleconv() is obviously not a public function and thus not meant for us to play with.
msg21992 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-26 19:05
Logged In: YES user_id=357491 Started a thread to discuss trying to deal with this before 2.4.a3 . Can be found at http://mail.python.org/pipermail/python-dev/2004-August/ 048395.html .
msg81447 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-02-09 06:55
Out-of-date?
msg81470 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-02-09 18:52
It's probably out of date. I will check if it is still failing tonight or tomorrow probably.
History
Date User Action Args
2022-04-11 14:56:06 admin set github: 40709
2009-04-02 04:24:00 brett.cannon set status: open -> closedresolution: out of date
2009-02-09 18:53:00 brett.cannon set assignee: jackjansen -> brett.cannonmessages: +
2009-02-09 06:55:31 ajaksu2 set nosy: + ajaksu2messages: +
2004-08-07 13:23:55 ronaldoussoren create