From: Michal Suchanek <hramrach@...>
Date: 2008-01-14T21:46:34+09:00
Subject: Re: does ruby's strftime not attempt POSIX-compliance?

On 12/01/2008, Suraj Kurapati <snk@gna.org> wrote:
> Jochen Hayek wrote:
> > Pls let me assure you in the beginning of this note, that it's
> > not my intent to start any flame war and also that I do not want
> > to offend anybody honorable.
>
> Ah, don't worry about it. In general, the audience here on ruby-talk
> is quite open-minded and respectful -- or so I would like to think. :-)
>
> > It's only about reasonable employment of good willing
> > programmers' resources and constructive use of pre-existing
> > software and standards like glibc, POSIX, ...
>
> Good, you are correct to be concerned!
>
> >>> Suraj Kurapati wrote:
> >>>> See this post for an example:
> >>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/57474
> >
> > The article referred to here talks about an interpreter patch
> > dated around 2002, that did not make its way into "MRI" by now,
> > de facto it's not part of 1.8.6, neither is it part of 1.9, let's
> > call it dead therefore. I would love to learn, that I am not
> > right there, but I do fear, I am.
> >
> > If I understood Matz correctly, then "1.9 calls setlocale() ...
> > for LC_TYPE" *internally* and obviously setting any of the LC_*
> > environment variables of a ruby script has *no* *effect*
> > *whatsover*.
>
> Hmm, I thought Matz said that Ruby 1.9 does this:
>
>   setlocale( ENV['LC_TYPE'] )
>
> instead of this:
>
>    setlocale( 'C' )
>
> Matz, would you please clarify?
>
> > Apparently these env. variables get overwritten within the
> > interpreter, let's consider this locale setting as "*frozen*", and
> > is my assumption correct, that various rather "central" software makes
> > uses of this *frozen* locale, I mean e.g. all the library code,
> > that handles HTTP protocol date/time strings.
>
> Correct.  A Ruby 1.8 script can only change the locale using the
> ruby-locale library.
>
> > Therefore that "central" code would break, if the interpreter and
> > its "kernel library code" would get the *frozen* locale setting
> > removed.
>
> Good point.  I never realized this!
>
> > But wouldn't it still be a good idea, to give the world, what
> > (g)libc actually already implements, I mean all the features
> > directed by those LC_* env. variables, e.g. language/region
> > dependant date/time strings, currency, thousands/decimal
> > separators, etc. pp.?!!!!
>
> Agreed.
>
> > I mean it shouldn't be that hard to cure the code, that depends
> > in turn on that frozen locale setting, and further on to remove
> > this freezing, right?
>
> Ah, you are hinting at a setlocale() method that accepts a block:
>
>   # assuming that Ruby has a Kernel#__set_locale__ method
>   class Kernel
>     def set_locale *args
>       if block_given?
>         old = locale
>
>         begin
>           __set_locale__ *args
>           yield
>         ensure
>           __set_locale__ old
>         end
>       else
>         __set_locale__ *args
>       end
>     end
>   end
>
>   # using C locale out here
>
>   set_locale( LC_TIME, 'de_DE' ) do
>     # do stuff with German locale
>   end
>
>   # using C locale out here (again)
>

As far as I know locale is set for the process, not for thread. Since
ruby is multithreaded this method of dealing with locale would be very
unsafe. Some libc functions that use locale use the one that was set
up by setlocale, some can even use one provided in a special argument.

Either way ruby should not use them for its core functionality, and
even cannot as its basic data types are mostly different from the C
basic data types. However, you could extend the ruby-locale library to
provide bindings to some of the more useful libc functions that depend
on locale (if it does not yet).

Thanks

Michal