Re: [brlcad-devel] comgeom-g bug

[Tom B. <tom...@gm...>]

On Fri, Apr 6, 2012 at 16:44, Christopher Sean Morrison <br...@ma...> 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