Re: Usage of strncpy in the kernel

>    [...]

> Changing that strncpy to a strlcpy will no longer zero-fill and will
> therefore export kernel stack trash to userland, which is considered
> an information leak even if it's mostly harmless.

I would say there is a place for a cross between strlcpy and strncpy:
something that fills the entire destination array, ensuring the last
byte is a NUL.  Basically, a wrapper around

	strncpy(a,b,c);
	a[c-1] = '\0';

As a strawman, I'll suggest strfcpy, f for `fill', though someone has
probably used it for something already.

I'd also say there is a (smaller) place for a routine which takes a
strncpy-style quasi-string (ie, NUL-terminated unless the whole array
is occupied) and copies it to another such, taking the sizes of both
the source and destination.  This would be most useful when the sizes
are externally specified, with neither obviously larger than the other
(say, sizeof(foo.name) and sizeof(bar.prop), where foo and bar are of
types defined by API include files).  At present, there is no good way
to perform such a copy; the least ugly I see is something like

	if (sizeof(foo.name) > sizeof(bar.prop)
		...
	else
		...

trusting dead code elimination to remove the unused arm (which
therefore likely will not get tested and thus can harbour a latent bug
until ported to a machine with unusual foo.name and/or bar.prop sizes).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B