On Apr 6, 2012, at 4:34 PM, Tom Browder wrote: > I think I've found the problem, but I think it may not all be > comgeom-g's fault but rather a confusing libbu function: > > Look at function bu_strlcpym. It looks like it's supposed to be a > safe version of strncpy/strlcpy by always ensuring a null-terminated > string, but I think a casual user might not realize the consequences, > to wit:
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. The problem is that strncpy() has a secondary error-prone use for copying memory buffers (i.e., not C strings) too. You can use strncpy() to completely fill a memory buffer and end up with NO terminating \0 character. I suspect comgeom-g relied on that behavior. A couple years ago when efforts began to harden code, all instances of strncpy() were modified to our new wrapper for long-term safety/maintenance/security. That worked for 99% of our use-cases where C strings were being copied and the remaining 1% cases where memory buffers were being manipulated were manually changed to memcpy(). Alas, I'd bet there is one or more buffer cases in comgeom-g that were mistaken for a C string. > Note that the supposedly safer bu_strlcpym still has the other strlcpy > bug of not checking the destination for sufficient size. It's not a bug, there's no way to actually "know" the real destination size. [1] There's just the size passed. As it is, it either uses strlcpy(), which guarantees \0 termination, or uses strncpy() which does not and then manually guarantees \0 termination. > I'm still looking for a similar existing function but am open to suggestions. > > Hm, what about using a bu_vls! For a converter, that's probably a better solution. Otherwise, the memory buffers will need to be increased in size by 1 byte (so we can ensure \0 termination) and the size parameter being passed to bu_strlcpy() then increases by 1 byte. Cheers! Sean [1] The deficiencies of strncpy() and reason for strlcpy() are an interesting academic read for folks interested: http://static.usenix.org/events/usenix99/full_papers/millert/millert.pdf http://www.gratisoft.us/todd/papers/strlcpy.html http://blogs.23.nu/ilja/2006/03/antville-11452/ ------------------------------------------------------------------------------ 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
