In message <Pine.NEB.4.21.0007281705590.9040-100000@server.int.duh.org>,
Todd Vierling writes:

>On Fri, 28 Jul 2000, Jonathan Stone wrote:


>: 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.)

_Whew_. Okay, cool.  Please retroactively turn down the volume
on my previous messages ;).


>Personally, I think so.  The open-ended nature of [v]sprintf() has run into
>problems time after time, 

Has this really happened in kernel code? If it really has, i guess
its worth being a bit more defensive.  I'm thinking more of boot-time
driver messages, where its pretty obvious if something breaks.


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

To repeat what I said earlier (privately): I was more concerned about
the people-time cost in maintaining Yet Another Fiddly Variant of a
kernel module. Whether it's Coda, or Raidframe, or in-kernel smb
clients, or IPX, or whatever.

If {Free,Open}BSD also buy-in into nuking kernel [v]sprintf(),
i'd be  happier.