Re: new module 'strlcpy'

[Paul Eggert]

On 09/27/2017 05:35 PM, Bruno Haible wrote:
> strlcpy with __warn_unused_result__ is the best solution for this task.

No it's not, because strlcpy always computes the string length of the 
source, and that is neither necessary nor desirable. Furthermore, in the 
bad style of programming that uses strlcpy, it's often acceptable to 
ignore the result since the programmer *wants* silent truncation. That 
is what strlcpy means in OpenBSD etc., and we shouldn't be trying to 
reuse their name for a function with different semantics.

A better way to fix the test case is to remove its arbitrary limit on 
month name lengths. That way, it won't need snprintf or strlcpy or 
strncpy or anything like that. And it'll be following the GNU coding 
standards better. I can propose a patch along those lines, if you like. 
I do not want Gnulib to promote the use of strlcpy; that's a step in the 
wrong direction.

> If the same standards were set for test code
>     than for application code, it would become even more tedious and
>     boring to write unit tests than it already is.
In that case, snprintf suffices: maybe snprintf is not good enough for 
production code, but it's plenty good for this test case.

If you really want a function whose semantics are like strlcpy's but has 
__warn_unused_result__ semantics (and while we're at it, also does not 
count overlong sources, because that's silly), then I suppose we could 
invent one and use it for Gnulib. But we should not call it strlcpy, and 
we shouldn't use it in production code.