> The delim_fmt is mostly created from a constant string passed into the > function, but it does have a '%n' at the end of the string, used to make > sure that it did, in fact, read in the delimiter (by checking that len > == delim_len). Since the spec says that %n shouldn't increment the > return value of scanf, this means that the return value will always be 0 > --- so trying to check that part_n == 1 always fails, making > bu_scan_fastf_t return after only scanning one input.
Ah, that makes more sense. I’ll add a comment to clarify as that detail isn’t obvious, even doubly so since this was a source of failure. It also probably implies the function is broken if someone tries to use ‘%’ as a delimiter. The implementation should probably be iterating over the delimiter chars one at a time into a char[4] while validating and escaping %, which would also avoid the need for dynamic memory. Regardless, thanks for the clarification! Cheers! Sean ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
