This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: [PATCH] codecvt<wchar_t, char, mbstate_t>


>Yes, this locale does not make much sense, since the US does not use Euro.
>en_US.ISO-8859-1 or en_US.UTF-8 might be better.

en_US.UTF-8 sounds good. Andreas can you verify it would work?

>std::locale create_named_locale(const char* s)
>{
>  locale loc;
>  try
>    {
>      loc = locale("foo");  // Throws runtime_error if "foo" is
>                            // not a valid locale name for this
>                            // system.
>    }


and perhaps

#ifndef _GLIBCPP_NAMED_LOCALES

>  catch (runtime_error&)
>    {
>      exit(77); // Dejagnu magic number so this doesn't count
>                // in the summary
>    }

#endif

>  return loc;
>}
>
>and then replace
>
>locale loc ("foo");
>
>with
>
>locale loc (create_named_locale("foo"));


I like this idea very much. If Dejagnu can be taught to learn error
codes than everything will be much better, and all the tests that are
currently throwing uncaught exceptions can be suitably modified to XFAIL
on these hosts.

That was kind of my plan at the beginning, but I didn't do the last
step. Also, I got a bit enthralled by the verbose terminate handler. Can
you figure out how to do it?

There is no configure-time way to figure out if named locales are
working. This stuff is the closest: 

/config/locale/g*/c_locale.h:
#define _GLIBCPP_C_LOCALE_GNU 

-benjamin


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