On Fri, Apr 6, 2012 at 16:02, Christopher Sean Morrison <[email protected]> wrote:
>
> 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.
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:
} else {
dst[size] = '\0'; /* sanity */
}
What would be wrong in changing that to:
} else {
dst[size] = '\0'; /* sanity */
}
(except that it wouldn't mimic strlcpy exactly, except that youe
aren;t anyway: "Note that a byte for the NUL should be included in
size")
-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
