>>b/ could you please explain why it is necessary to strlcpy() in this
>>case?  You've just made it necessary to add strlcpy() to the next version
>>of bmake for little benefit - copying a fixed sized string into a known
>>sized buffer isn't the stuff of buffer overflows.
>
>	i'm not finished yet.  there are other strcpy i will be updating.
>
>>Or are you planning to replace all str*cpy calls in the tree with strlcpy?
>>I'm sure there are places that warrant it - even within make - but
>>this specific case doesn't appear to be one.
>
>	yes

	i've finished audit, and it seems that make(1) cannot benefit from
	strlcpy().  copies/string ops are made either
	- right after enough-size malloc
	- region with unknown size due to parameter passing, like util.c:getwd()
	so i backed it out.

itojun