stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicole Willson" <>
Subject RE: FW: 17116,756,000
Date Wed, 09 Aug 2006 16:56:57 GMT
I had to do it for every call to  Just change it like this:
	// const std::messages_base::catalog cat = (,
 	const std::string cat_name_str = CAT_NAME;  
	const std::messages_base::catalog cat =
(, loc);

The problem was that it was returning some number like -5475, instead of
the number it should have been returning and causing the close to fail.
This is a compiler bug that I've not yet been able to document with a
testcase.  Fortunately, it is easy to workaround, if somewhat annoying.

I've also solved the problem with the stress_test.  Since the NLSPATH
variable is being used, it can't have the .cat at the end of the catalog
name - NLSPATH has already added that, so it is looking for and of course, not finding it.  I'm surprised that
this would work on any system.


-----Original Message-----
From: Martin Sebor [] 
Sent: Wednesday, August 09, 2006 9:53 AM
Subject: Re: FW: 17116,756,000

Nicole Willson wrote:
> There is a workaround that keeps it from aborting - basically instead 
> of calling x = foo("some string");, you set the string ahead of time, 
> ie Char *some_str = "some string"; x = foo(some_str);

Thanks for sharing that! What's foo and what line of the test is the
call that needs to be changed on? On the latest trunk the abort happens
on line 439 where there's no string argument

    429  template <class charT>
    430  std::messages_base::catalog
    431  open_catalog (const std::messages<charT> &msgs,
    432                const char *cat_name, const std::locale &loc,
    433                bool expect_exception, const char *cname, int
    434  {
    435      std::messages_base::catalog cat = -1;
    437      try {
    438          // an already closed cat should throw an exception
    439          cat = (, loc);
    441          rw_assert (!expect_exception, 0, line,

> This keeps it from screwing up the return of foo. 
> The failures that I am now getting are failed assertions because 
> catopen fails and returns a -1 instead of the catid needed by

Unless we're running into some undefined behavior exposed by the
compiler (which might be corrupting the name of the catalog or some libc
internal data) the catopen() call should succeed with xlC just as it
does with gcc on the same machine. I.e., it doesn't look like there's a
simple logic error in the test.


View raw message