classification
Title: test__locale fails on MacOS X
Type: Stage:
Components: None Versions: Python 2.4
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: ajaksu2, brett.cannon, jackjansen, ronaldoussoren
Priority: normal Keywords:

Created on 2004-08-07 13:23 by ronaldoussoren, last changed 2009-04-02 04:24 by brett.cannon. 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) 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
2009-04-02 04:24:00brett.cannonsetstatus: open -> closed
resolution: out of date
2009-02-09 18:53:00brett.cannonsetassignee: jackjansen -> brett.cannon
messages: + msg81470
2009-02-09 06:55:31ajaksu2setnosy: + ajaksu2
messages: + msg81447
2004-08-07 13:23:55ronaldoussorencreate