On Apr 7, 2012, at 9:12 AM, Tom Browder wrote: > On Fri, Apr 6, 2012 at 15:34, Tom Browder <[email protected]> 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 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
