stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
Date Tue, 01 Apr 2008 22:36:37 GMT
 

>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>  
>> 
>>> Travis Vitek commented on STDCXX-742:
>>> -------------------------------------
>>>
>>> This is happening because we don't use the -qrtti=dynamiccast 
>>> option. We internally use a dynamic_cast to determine if the 
>>> facet is of the correct derived type, but if dynamic_cast 
>>> isn't supported we use a C style cast, and that returns bad results.
>>>
>>> This case is essentially the same as STDCXX-664. We didn't add 
>>> -qrtti=dynamiccast back then, and we just worked around the 
>>> issue in the test. It seems to me that we should have added 
>>> the flag. Would this be a binary compatible change?
>>>
>> 
>> What are the thoughts on this? There was some discussion
>> [http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
>> VisualAge C++ compiler, but it petered out. 
>
>Is there any way to turn on rtti using a pragma? That way we could
>enable it only for translation units that included <locale> and we
>wouldn't be shoving the option down the throats of users who don't
>care about named locales.

No, there is no pragma for this. Even if there were we would need to do
some hacking to get it to work. We try determine if dynamic_cast<>()
exists and is functioning correctly at configuration time. If that
config test fails, we define _RWSTD_NO_DYNAMIC_CAST. So even if we
managed to enable rtti when <locale> was included, we would need to
'fix' the _RWSTD_NO_DYNAMIC_CAST and _RWSTD_DYNAMIC_CAST macros. Ewww..

>
>Btw., does XLC++ itself correctly handle the test case mentioned
>in the thread, even without -qrtti? (It's possible to get some
>simple cases to work even w/o the option but not all of them).
>

I'm not absolutely sure what you're asking. It sounds like you are
asking if the Standard C++ Library implementation that ships with XLC++
has this same problem. The answer to that is no...

    $ type t.cpp
    #include <locale>
    #include <cstring>
    #include <cassert>

    template <class charT>
    void test_has_facet (const char *loc_name, const char *cname)
    {
        const std::locale loc =
            loc_name ? std::locale (loc_name) : std::locale ();

        typedef std::messages_byname<charT> ByName;

        const bool byname = loc_name
            && std::strcmp (loc_name, "C");

        const bool facet_exists = std::has_facet<ByName>(loc);

        assert (byname == facet_exists);

        try {
            // verify that use facet throws an exception only
            // for the default and "C" locales
            std::use_facet<ByName>(loc);

            assert (byname);
        }
        catch (std::exception &ex) {
            assert (!byname);
        }
    }

    template <class charT>
    void test_messages (charT, const char *cname)
    {
        // exercise has_facet and use_facet in the default locale
        test_has_facet<charT>(0, cname);

        // exercise has_facet and use_facet in locale("C")
        test_has_facet<charT>("C", cname);
    }

    int main (int, char*[])
    {
        test_messages (char (), "char");

        return 0;
    }

  $ xlC t.cpp -o t && ./t
  $

If I run the same code under stdcxx, I get the following

  $ gmake t && ./t

  <snip>

  Assertion failed: byname == facet_exists, file t.cpp, line 18
  IOT/Abort trap (core dumped)
  $

Travis

Mime
View raw message