On Fri, 28 Jul 2000, Jonathan Stone wrote:

: First, Do we really want to remove [v]sprintf permanently?  Doesn't
: that make for yet more very-low-payback nuisance changes when
: importing kernel source which originates elsewhere, and tracking
: changes from elsewhere?  (For new netbsd-originated code, sure.)

Personally, I think so.  The open-ended nature of [v]sprintf() has run into
problems time after time, and the extra argument passing is a small price
(there's really no other overhead, if you compare vsprintf vs. vsnprintf in
subr_prf.c).  It also makes the programmer think long and hard about reusing
buffers in constructs like:

    char *buf = go_do_something_return_static_buffer();
    if (flag)
         sprintf(buf, ...);

...several of which are in NetBSD-originated code.

The printf routines are not used in heavy-repetition, performance-critical
routines, except as error or diagnostic-warning reporting.

: Second: Does this change imply the "zero-fill until end of specified
: length" semantics of userlevel [v]snprintf?

No, it doesn't, and I should probably document that in kprintf.9.  (At the
moment, [v]snprintf() is not even in kprintf.9, and I've been rewriting
that page to add it, as well as make a page for bitmask_snprintf.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.
=====
Note: This e-mail represents opinion of its author, and not of Wasabi Systems.