generic locale

Loren James Rittle rittle@latour.rsch.comm.mot.com
Tue Feb 25 09:07:00 GMT 2003


In article <20030222210456.GA9381@disaster.jaj.com>,
Phil Edwards<phil@jaj.com> writes:

> . o O (Loren, reading list mail on the weekend? what the-?)

Ah, what can I say?  I was at work late on a Friday night which then
slipped into Saturday morning.

>> (b) At least throw an exception in generic for all user instantiations
>> of locale() objects unless they map to the "C" (or ""?) locale.

> Can go for this as a short-term solution, sure.  Especially if the
> exeception's what() includes something along the lines of "this is a
> temporary band-aid, see http:.....".

OK, (trivial) patch to catch attempts to create non-C locale objects
is included for comment.  Due to caller context, we only need to catch
"C" here.  When "POSIX", "C", "" (where LC_ALL environment is set to
"C" or "POSIX") is provided to std::locale::locale(), it will not
throw and it will operate exactly as before.  All other situations
(which were not handled properly by the baseline generic
implementation) involving calls to std::locale::locale() will throw.

As expected, this causes another 30-40 22_locale execution tests to
fail.  (Expected, because some tests had set a locale but didn't care
that it wasn't really accurate.  I don't consider this a regression however...)

Ideally, we would mark all these failures conditionally on how
libstdc++-v3 was configured (not readily possible with dg- framework
AFAICS); figure out how to implement Martin's idea (not readily
possible in the current code framework AFAICS); or (as a last resort?)
rework them to catch the exception thrown by the generic locale implementation.

The following tests fail for the same reason:

FAIL: 27_io/filebuf_virtuals.cc execution test
FAIL: 27_io/ios_members.cc execution test
FAIL: 27_io/ostream_inserter_arith.cc execution test
FAIL: 27_io/streambuf_members.cc execution test
FAIL: 27_io/stringbuf_virtuals.cc execution test

Not really a regression either but I'd rather not flag such an issue
outside 22_locale.  As a test of the proposed technique, I added a
try-catch block and related check to ensure the caught exception
looked right (patch for other four are similar).

Do the other library maintainers agree that this line is an
improvement which better reflects the state of ports using the generic
locale implementation?  Actually, I guess I don't really care about
the state of the testsuite failure profile (within 22_locale).  I'd
rather install the generic/c_locale.cc patch and move on to the
enhanced-generic which will attempt to provide better generic locale
support.

Regards,
Loren

	* config/locale/generic/c_locale.cc (locale::facet::_S_create_c_locale):
	Throw a runtime error when request for non-supported locale is seen.

Index: libstdc++-v3/config/locale/generic/c_locale.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/config/locale/generic/c_locale.cc,v
retrieving revision 1.5
diff -c -r1.5 c_locale.cc
*** libstdc++-v3/config/locale/generic/c_locale.cc	28 Nov 2002 12:23:53 -0000	1.5
--- libstdc++-v3/config/locale/generic/c_locale.cc	24 Feb 2003 22:28:19 -0000
***************
*** 212,220 ****
      }
  
    void
!   locale::facet::_S_create_c_locale(__c_locale& __cloc, const char*, 
  				    __c_locale)
!   { __cloc = NULL; }
  
    void
    locale::facet::_S_destroy_c_locale(__c_locale& __cloc)
--- 212,224 ----
      }
  
    void
!   locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s, 
  				    __c_locale)
!   {
!     __cloc = NULL;
!     if (strcmp (__s, "C"))
!       __throw_runtime_error("attempt to create locale from unhandled name in generic implementation; see http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html");
!   }
  
    void
    locale::facet::_S_destroy_c_locale(__c_locale& __cloc)

As an proof of concept only:

Index: 27_io/stringbuf_virtuals.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc,v
retrieving revision 1.6
diff -c -r1.6 stringbuf_virtuals.cc
*** 27_io/stringbuf_virtuals.cc	24 Feb 2003 18:22:58 -0000	1.6
--- 27_io/stringbuf_virtuals.cc	25 Feb 2003 08:35:15 -0000
***************
*** 22,27 ****
--- 22,29 ----
  
  #include <sstream>
  #include <testsuite_hooks.h>
+ #include <stdexcept>
+ #include <cstring>
  
  void test01()
  {
***************
*** 160,166 ****
    test02(in2, false);
    test02(in3, false);
  
!   test08();
    test09();
    return 0;
  }
--- 162,173 ----
    test02(in2, false);
    test02(in3, false);
  
!   try
!     {
!       test08();
!     }
!   catch (std::runtime_error ex)
!     { VERIFY (std::strstr (ex.what(), "unhandled name in generic")); }
    test09();
    return 0;
  }



More information about the Libstdc++ mailing list