On Mon, 2008-11-10 at 21:08 +0000, Scott Lawrence wrote: > On Mon, 2008-11-10 at 14:41 -0500, Dale Worley wrote: > > On Mon, 2008-11-10 at 19:22 +0000, Scott Lawrence wrote: > > > 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. > > > > Actually, UtlString is constructed so that after the length() bytes, > > there is always a NUL byte. > > I didn't think that was always true, but it's possible...
I thought it was a design principle of UtlString, so that one could use them "on top of" regular C strings, or pointer-and-length strings equally. But I admit I haven't checked all the UtlString routines to verify that the implementation does this all the time. > do you think I > should modify the setLength method to enforce that by adding a NUL > following the new length? Easy enough... That's probably best. But if you don't, make sure that you put a big warning in the .h that the caller has to ensure that there is a NUL properly placed after the last data byte. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
