>this change, among many others, is converting *safe* strc*()
   >calls into strl* ones.  is there any particular reason you are
   >doing this?
   
   	many of seemingly-safe strcpy are safe because:
   	- foo.h defines destination buffer bigger than/same size as source
   	  (intentionally or by coincidence?  they are hardcoded numbers, not
   	  macros, in many cases!)
   	- MALLOC(len + 1) is performed right before strcpy
   
   	by using strlcpy, we can avoid any overrun mistakes even when foo.h
   	changes, MALLOC() changed by someone, or whatever assumption changes.

in (nearly?) all the cases i looked at the "assumptions" were present
only in the code of the block changed.  in particular the MALLOC() case
you present is *100%* a red-herring.  these are *exactly* the safe uses
of strc* that should be left alone.  avoiding implicit assuptions such
as your "foo.h" example is a good idea (i'm sure they exist even though
my sample of your changes didn't seem to include any like that) but only
those cases seem to be worth changing.
   
   >you are making the kernel slower for *no good
   >reason*.
   	  
   	i am doing it with reason.  care to provide asm version of strlcpy? :-)

but it's not necessarily a *good* reason.  please stop converting any
more code until it's shown to be a good reason.  my original post about
this issue asked for actual *problems* being solved to be listed, but
besides the "foo.h" case (of which no actual bugs have been fixed?) i'm
really not seeing anything yet.


.mrg.