[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new module 'strlcpy'

From: Paul Eggert
Subject: Re: new module 'strlcpy'
Date: Wed, 27 Sep 2017 18:23:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]