Anton Pevtsov wrote:
This verfies similar to http://issues.apache.org/jira/browse/STDCXX-175
possible problems.
Yes, it is tricky, the passed array has not enough length (-1 is
interpreted as max_size() + 1),
but I think that the method implementation should not create the string
with such length.
Yes, that's what I'm thinking as well. I don't think it ever
does.
Formally the behaviour should be undefined, so we can remove these tests
as more strict than required by the standard.
I see. I think you're right, it is undefined.
But I suggest to leave them: all methods pass these tests and the
exception throwning looks more useful than undefined behaviour for this
situation.
I agree with that in general but I don't think we can define
the behavior in all these cases. Consider these two examples:
string s ("abc");
s.find ("def", 0, 5);
s.find ("def", 0, -1);
There is no way for us to detect that 5 is too large in the
first call to find() so the the function returns npos because
"def" is not found. But in the second example which is equally
invalid we throw, even though we could just as easily return
npos. I think we might as well return npos is all such cases
for consistency. Doing so also simplifies the implementation.
Unless you see something wrong with this change, I will go
ahead and change string::find() et al not to throw. Then we
will modify the tests to exercise this new behavior. Let me
know your thoughts.
Martin
