Re: Re: [PATCH v3] Implement strlcpy [BZ #178]

[ricaljasan <ricaljasan at pacific dot net>]

I don't have an opinion on strlcpy itself, but I've been following this
discussion and I think the best compromise I've heard is found in these
two statements:

On 11/07/2015 04:48 PM, Tolga Dalman wrote:
> Also, I would like to see a comment like "Do not use this function unless
> you really know what you do. Consider strncpy instead." in the documentation
> (and man pages, eventually).

On 11/07/2015 05:51 PM, Rich Felker wrote:
> My proposal has always been to implement it in glibc with the correct
> semantics matching the original BSD function in all corner cases,
> document it well, and note that it's not recommended but without
> throwing too much ideology/propaganda into that note.

As a glibc user, I take the manual at its word.  If it says to avoid use
of a function (and there are quite a few it says that about*), I will.
Rather than inclusion in glibc and subsequent blacklisting via the
manual though, I don't see any harm in providing documentation to the
effect of, "These are the appropriate use cases for this function;
otherwise it should be avoided."

I appreciate that some people want to provide what they feel is a safer
implementation of an error-prone routine.  Despite a pathological urge
to always reinvent the wheel, that is exactly one of the things I rely
on the providers of my C library (you all) to do.

Rical


* Some examples:
https://www.gnu.org/software/libc/manual/html_node/Charset-Function-Overview.html#Charset-Function-Overview
https://www.gnu.org/software/libc/manual/html_node/Basic-Signal-Handling.html#Basic-Signal-Handling
https://www.gnu.org/software/libc/manual/html_node/Formatted-Output-Functions.html#Formatted-Output-Functions