On Fri, Apr 6, 2012 at 16:44, Christopher Sean Morrison <[email protected]> wrote: > > On Apr 6, 2012, at 5:29 PM, Tom Browder wrote: > >>> That bu_strlcpy() function is basically an implementation/wrapper for >>> strlcpy(). It IS still a safer way to copy strings than strncpy() simply >>> because it ensures NULL termination and doesn't require the caller to >>> inconsistently subtract a byte for null -- they just pass the actual size. >> >> Hm, it looks to me like you have to pass size+1 as it is now (i.e., >> include the null in the string and count it in length), see this in >> bu_strlcpy: > > The "actual size" is the actual memory size of the destination, not the > string size:
Right, I see, and that's why the strncpy semantics should be used instead of strlcpy in the problem code (2 instances). All the rest of the comgeom-g strlcpy instances use the receiving buffer size instead of the source string size. I'm turning those two instances to vls and I think that will cure the immediate problem. Thanks, Sean. -Tom ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
