[interfacekit] Re: A patch for BString


On 2003-11-06 at 11:09:30 [+0100], you wrote:
> 
> I have finally found the time to finish the patch (which is rather large,
> I'm afraid...).
> 
> Due to the comments on the list, I have decided to make as few changes to
> the behaviour of BString (as compared to R5) as possible and only change
> things if the behaviour of BString is a clear bug or *very* annoying.
> 
> A summary of the changes:
> 
> - memory-allocation has been centralized and BString is now capable of
>   handling out-of-memory situations (somewhat) gracefully: The string
>   is just left as is (as it was before the call).
> 
> - all length - arguments are clamped to the real length now, meaning that
>     BString s( "some text");
>     s.Remove( 4, 30);
>   now correctly yields " text" (not "some text" as R5 does).
> 
> - passing negative values to a fromOffset argument causes BString to return
>   B_ERROR if that is possible or send the app straight to the debugger.
>   An exception to this rule are the Insert()-methods which accept negative
>   values just like the R5-implemantation does (but we avoid crashing for
>   offsets that exceed the string-length).
> 
> - passing a insertion-position that exceeds the string-length sends the
>   app to the debugger.
> 
> - passing a fromOffset/beforeOffset to any search-method returns B_ERROR.
> 
> - BString's only error-code is now B_ERROR just to be compatible with the
>   documentation (R5 only ever returns B_ERROR, it crashes in cases where
> the
>   openbeos implementation used to return B_BAD_VALUE).
> 
> - I have streamlined the (I)Replace... and Remove... - methods such that
>   BString never uses _OpenAtBy() / _ShrinkAtBy() inside a loop. This way
>   it avoids the pathetic performance of the R5-implementation (which is
>   indicated by the new tests that use large(ish) datasets).
> 
> - BString should no longer crash if given any weird offset/length arguments.
> 
> - Several tests have been added.

Very nice!

> There is (at least >:oP ) one open problem: Since some tests will trigger a
> call to the debugger if compiled with DEBUG, the unit-test will never pass.
> That's a bit awkward, so I have thought about using a signal-handler in the
> test-app that could be used to implement a check for a signal like this:
> 
>     BString s;
>     CPPUNIT_ASSERT_DEBUGGER( s.Insert( "dummy", 20));
> 
> Does this kind of stuff already exist in cppunit? Is it feasible at all?

AFAIK, it is not implemented and at the time I hit this problem myself (a 
year or so ago) I thought it wasn't possible to solve... Now I know better. 
:-)

Catching signals doesn't seem to work -- I wrote a little test handler 
catching any signal, but a debugger call isn't caught. What probably will 
work is to install a debugger (cf. <debugger.h>), but it's quite a bit of 
overhead, for the debugger must live in another team (how I understand it).

A better solution seems to redirect the debugger() invocation. By accident, 
not too long ago, I wrote some code that allows to redirect calls to 
functions that live in a different shared object at least. Since debugger() 
is defined in libroot, that should be just fine for invocations from 
libbe/libopenbeos.

If noone objects, I can try and extend our unit test framework to support 
testing for debugger calls.

> In general, it seems obvious that BString needs some more work at a later
> stage. IMHO the idea of accepting negative offsets/values does make sense
> and there is a need for throwing exceptions (at least bad_alloc) but I
> believe this is all work that should go into R2.

Yep, let's postpone this. There are more important things to be done at the 
moment, like getting a working system in the first place. :-)

CU, Ingo

Other related posts: