incubator-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: _RWSTD_REQUIRES throwing uncaught exceptions in tests?
Date Thu, 20 Mar 2008 04:49:52 GMT


> Eric Lemings wrote:
> 
> Greetings,
>  
> I've been stepping through one of the string tests.  The
> std::string::at() member function is being called with a __pos value
> that is >= size() causing the _RWSTD_REQUIRES assertion to fail.  It
> seems to be throwing an exception, which is not being caught, as a
> result.  Consequently, the whole test program raises an ABRT signal.
> There are several such programs raising ABRT signals (on the Mac
> platform at least).
> 

Yeah, I looked at the build results for 21.string.access, and it doesn't appear to be failing
for this same reason on any other platforms.

One thing I noticed while looking at this is that the X-Platform view doesn't show all tests.
As an example, the 21.string.access test appears in all of the standard results pages [http://people.apache.org/~sebor/stdcxx/results/],
but it doesn't appear in the X-Platform view [http://people.apache.org/~sebor/stdcxx/results/builds].
Maybe this is something that Martin should look at. Martin?
 
> Now there's certainly nothing wrong with the test case testing
> out-of-bounds behavior but it should be catching any possible
> exceptions, shouldn't it?  Assuming the std::string::at() function
> does not have a no-throw guarantee.
> 

I'm assuming that you are asking why there is no catch (...) block to eat all exceptions.
I don't really have a good answer for that.

I think that since the string implementation is only supposed to throw std::length_error and
std::out_of_range, it may be acceptable to catch only those exceptions in the test for string.
Of course some other exception may be thrown indirectly [ex. std::allocator<T>::allocate()
may throw std::bad_alloc], but those cases should probably not be exercised by the string
test.

If the problem is what I think it is, adding a catch all probaly won't help. I'm _guessing_
that the definition of std::exception [which is based on output of config tests] isn't consistent
with what is provided by the runtime library.

Travis

> Brad.
>  


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message