On Mon, 2008-11-10 at 13:10 -0500, Dale Worley wrote: > On Mon, 2008-11-10 at 09:57 -0500, Robert Joly wrote: > > > [<<BOB JOLY>>] This makes sense but in reading the > > example, I wonder about null-termination > > considerations, if any When we set the content of the > > data buffer 'manually', must we supply a NULL > > termination? Should the capacity() value we > > specify account for the NULL termination? When I set > > the length, does that exclude the NULL termination? > > The string contents of a UtlString are always supposed to have a NUL > after them. This lets you use the result of UtlString::data() for input > to C library functions. If one directly writes a string into the > string's buffer, who is responsible for supplying the ending NUL? > > >From the code, it looks like mCapacity is intended to include the NUL at > the end of the string. That is, the maximum length is 1 less than > mCapacity. (The documentation does not make this clear at all.)
UtlString is poorly named... it really should be UtlBuffer, since it is _not_ assumed that it is always null terminated. Many of the methods that copy to and from strings always add the null, though, and there are probably lots of bugs in the code that assume it's always there. If you do the copy with methods that just take a pointer and a length, you don't always get the null. The point of this method is to give you direct external control - it is certainly possible to mess things up. In the one use of it I've made: http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXtackLib/src/net/NetBase64Codec.cpp?r1=13967&r2=13966&pathrev=13967 I found that I needed to add the null at the end of the string but _not_ include that null in the length in order to preserve perfect backward-compatibility with existing unit tests... _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
