In message <200404282322.42840@kleink.uid.et.reziprozitaet.de>Klaus Klein writes
[...]

>This very discussion has its cause in a change of code to make it
>take advantage of the particular behaviour of snprintf() which is
>widely regarded as making it suitable for secure programming with
>little effort.  Subtle modifications (like this one) to its kernel
>incarnation would raise that bar again because it would no longer
>behave the same everywhere.

I'd perhaps say "less insecure" instead of "secure", but yes, sure.

Personally, I dont see this as meaningfully raising a bar. Kernel
programming and userland programming *are* different. Attempts to hide
those differences can do more harm than good, by creating a false
sense of security and familiarity.

That said: I keep thinking, maybe we should design a truly safe
interface for the kernel uses mentioned so far; maybe call that new
function "slprintf()" (following strlcpy/strlcat), and be done with it.