[ python-Bugs-1005113 ] test__locale fails on MacOS X
SourceForge.net
noreply at sourceforge.net
Fri Aug 13 00:19:16 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: Nobody/Anonymous (nobody)
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: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