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.