Re: [brlcad-devel] comgeom-g bug [SOLVED]

[Christopher S. M. <br...@ma...>]

On Apr 7, 2012, at 9:12 AM, Tom Browder wrote:

> On Fri, Apr 6, 2012 at 15:34, Tom Browder <tom...@gm...> wrote:
>> I think I've found the problem
> 
> The original problem was a result of the getint and getdouble
> functions using the actual field input size when parsing an input line
> and the bu_strlcpy macros in those two functions promptly chopped off
> the last character as they are supposed to do.  I replaced the macros
> with the bu_vls_strncpy functions so the parsing is more intuitive in
> that actual field size is entered and the last character is not
> chopped
> 
> The problem prevented successful conversion on any input deck, and
> with the fix it now works on a complex TGM input file.

Excellent sleuthing.  The rework using a VLS should be a more robust solution too.

The  custom functions for extracting an int and double from a C string in comgeom-g are probably prime for refactoring.  Something for the code reduction candidates to think about given the timely relevance.  I know I've seen other instances in the code doing that same pattern.

Cheers!
Sean