[ python-Bugs-1005113 ] test__locale fails on MacOS X

SourceForge.net noreply at sourceforge.net
Fri Aug 13 00:32:04 CEST 2004


Bugs item #1005113, was opened at 2004-08-07 06:23
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470

Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Jack Jansen (jackjansen)
Summary: test__locale fails on MacOS X

Initial Comment:
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....

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-08-12 15:32

Message:
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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-12 15:19

Message:
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.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-12 12:40

Message:
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?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-07 12:14

Message:
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!

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 08:10

Message:
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)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470


More information about the Python-bugs-list mailing list