This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] libstdc++/7811

On Fri, Sep 06, 2002 at 11:55:26AM -0700, Roland McGrath wrote:
> > It's not just a good idea, it's the law.  The C++ Standard requires
> > std::locale::name() and std::setlocale() to use the same format for
> > composite locales.  This is a nontrivial requirement.
> I don't know what the C++ says about extra locale categories,
> but the sensible thing to do is to include all the categories setlocale
> understands in the composite name even if C++ doesn't do anything with
> them.  Otherwise, you could lose some settings going from a user's
> LANG environment variable -> C++ -> environment -> C setlocale.
> That case can be handled right by just preserving the user's setting.
> But if it's actually multiple LC_* vars -> C++ -> just LANG -> C,
> then you would want to make sure that the C++ code collecting environment
> variables collects all the ones that setlocale would.

Yes, for more recent glibcs it should include all 12
categories and use glibc composite format LC_CTYPE=foo;LC_NUMERIC=bar;...
On Solaris, AFAIK the composite format is like:
so the code has to be os specific.

One problem I see is that
locale::_Impl::_Impl(const char* __s, size_t __refs)
doesn't make a copy of __s string when putting it into _M_names array,
which looks like a bug to me - it can point to stale data RSN, and e.g. in
the case where we are constructing _Impl(getenv("LC_ALL")) it is enough to
change environment.

Also, I wonder whether the individual _M_names in case _Impl was
passed a composite name shouldn't be the LC_CTYPE/LC_NUMERIC etc. locales,
not the composite name.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]