The ups and downs of strlcpy()

> That's why I find the rejection of strlcpy *stupid*: it's not perfect but it's much better than strcpy or strncpy, and it's a step in the right direction for the many projects which don't use a library for strings handling.

+1
I am probably missing some strange security twist in my brain but IMHO it's not the glibc's maintainer task to say to their users what not to use unless if proven bad (in this case not better than strcpy/strncpy).
They should just look at if this functions adds something to their library and I do think it does. If people still can and probably will misuse these functions is IMHO not a good reason to keep it out of their library. And we are talking about a few bytes of code only.
Sometimes I really can get into the comments from Linus on the security purists (avoiding the 4 letter word here).

greets,
Staf.

It seems it so common to call strlen then another str* function that a new optimization pass was added to gcc 4.7 to keep track of strings length and thus avoid redundant passes on strings.

See gcc 4.7 release notes:
http://gcc.gnu.org/gcc-4.7/changes.html