[interfacekit] Re: more questions about BString

> Hi everyone,
> 
> when implementing the BString-patch we spoke about earlier, I tried to 
> follow the idea that the BString-class should clamp all input values 
> (offsets) to sensible values (0 <= offset <= length).

I find clamping all input values to be very unintuitive.
 
> As the resulting testrun shows, this causes the resulting behaviour to 
> differ from R5-BString in some ways:
> 
> - R5 allows calls to Insert( const char* str, int32 pos) with negative 
> positions, giving IMHO weird results...
>       Insert( "INSERT THIS", -1) 
> on an empty BString yields a string that contains "NSERT THIS". 
> This behaviour ist not at all documented by the BeBook.

You may want to check and see if it's actually inserting the
entire string before the data start point. (oh no!)  If it is,
that's a straight out bug that you need not support.  If it does
not, that seems to reflect a design decision, since that would
require flow control to give that behavior.  In which case,
do support it. :-)
 
> My suggestion would be to clamp negative offsets to 0 (yielding "INSERT 
> THIS" for the given example).
> 
> - Remove( int32 fromOffset, int32 length) 
> silently accepts fromOffset<0 (using 0), but doesn't clamp length likewise:
>       BString s("A String");
>       s.Remove( 4, 30);
> yields "A String" instead of "A St".
> 
> - the (I)Find...()-methods seem to always return B_ERROR if you pass a
> negative fromOffset. My patched methods clamp fromOffset to 0 and then
> execute the search, possibly yielding positive results.

I'm for negative numbers being an error, in particular: B_BAD_VALUE,
although the Be API is very spotty about when B_BAD_VALUE comes
back vs. B_ERROR. :-/  These params should probably be size_t anyway.... :-)
 
Andrew

Other related posts: