Re: [brlcad-devel] bu_vls_vprintf and Friends: Why?

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

On Jan 20, 2012, at 12:12 PM, Tom Browder wrote:

> While fooling with ./src/libbu/vls.c I wonder:  why the
> '[bu_vls_*print*' replacements for the "standard C facility?"

> They are not listed as replacements in HACKING (but probably should be
> if that is the desire).

They're not replacements, they're merely utility functions for manipulating libbu variable-length strings (vls).

The main reason for working with a vls instead of a null-terminated c string is automatically managed memory, consistent bounds checking, and more efficient access.  Several of the utility routines predate the prevalent standardization of the libc functions and others intentionally avoid some of the libc functions for performance, portability or security reasons.

Simple example, say I want to print some unknown quantity into a string buffer.  With C strings, you have to manually keep track of the buffer/memory size to make sure you don't exceed it.  If it's a buffer, you're screwed.  If it's dynamic memory, you have to repeatedly perform a potentially expensive realloc.  With a vls, it becomes a simple one-liner with the minimum happening under the hood, even avoiding those expensive allocations wherever possible. 

> If we are not to use the standard C '*print*' functions due to memory
> considerations, why not start with the libc code (under LGPL license)
> and modify it as necessary?

What's there basically is exactly that though undoubtedly BSD heritage and/or pre-standardization.  If they were to be brought up to date with some of the missing subtleties using external code references, it'd be more appropriate to look at BSD libc code.  That said, it's probably *significantly* easier and less risky to just add the missing feature (like the test case you identified).

Cheers!
Sean