discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localization of libc and number handling


From: Andreas Heppel
Subject: Re: Localization of libc and number handling
Date: Mon, 23 Jun 2003 16:22:06 +0200

On 2003-06-23 14:20:28 +0200 Alexander Malmberg <alexander@malmberg.org> wrote:

Andreas Heppel wrote:
<snip>


I'm not sure you should rely on being able to parse what -description
returns, but I think its behavior is correct. From what I've seen, all
methods that deal with locale and don't have an explicit locale argument
use the nil/default/c locale, so I'd expect -description to do this as
well.

The thing is, not I am relying on -description, but -floatValue of NSCell does (more or less, that is). Tracing this call down into the depths of GNUstep ends up with -description, which, as you already expect, uses nil as locale. Unfortunately, it is not me (or in this case Enrico), who is mixing up libc and GNUstep, but it's GNUstep itself, as the method -floatValue, for instance, of an NSString uses atof() on the value returned by -lossyCString. And -description comes into play, for instance, in NSCell's -setObjectValue. It could be avoided (if I understand the code properly) by employing a formatter for the cell. I haven't tried this, yet. No, I just checked NSNumberFormatter. It simply returns, guess what, -description for the object.
I looks a bit incomplete.
Nevertheless, IMHO, an NSNumber should take into account the user's locale when building it's description. At least it should take into account the (first) value in NSLanguages, in the hope that this is coherent with the LANG setting.

The question is, how can a consistent handling of locales between GNUstep and
the libc be achieved?

It can't. GNUstep can't change the locale or rely on it having any safe
values. I'd suggest either using only libc functions (which means that
you get to manage the libc locale yourself), or using only GNUstep
methods (which are supposed to use the OpenStep locale handling, but see
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3519&group_id=99 ).
How does OpenStep locale handling work?
I am not surprised at all about this error report, as in the depths og GNUstep libc functions are used (which are localized).


Cheers,
Andreas

--
Andreas Heppel

Mail: aheppel at web dot de
Home: http://www.andreasheppel.de

Check out Burn.app - the CD burning frontend for GNUstep
http://gsburn.sourceforge.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]