> 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. >
