Re: new module 'strlcpy'

[Jim Meyering]

On Wed, Sep 27, 2017 at 5:44 PM, Bruno Haible <address@hidden> wrote:
> I wrote:
>>    In some places the users
>>    will notice that strlcpy does not buy them much, compared to the
>>    "avoid arbitrary limits"[1] approach, and will switch over to what
>>    you call "GNU style". In other places, they will insert an abort()
>>    or assert() to handle the truncation case - which is *better* than
>>    the strncpy approach.
>
> For example, in gnulib's setlocale.c override. This file has fixed-size
> buffers and silent truncation - because it uses the "strncpy and set NUL byte"
> approach. As soon as someone (me) will use strlcpy with __warn_unused_result__
> there, he will change the code to do
>   - either dynamic allocation and no arbitrary limits,
>   - or provide a good alternative to the silent truncation.
> Either result will be better than the current one.

I have to agree that we need something, and it may even be spelled
strlcpy. It seems reasonable to allow new uses of strlcpy, given a
__warn_unused_result__ attribute -- that should prevent those new
users from ignoring that return value. I developed a strong aversion
to strncpy, and wrote this about it:
https://meyering.net/crusade-to-eliminate-strncpy/