On Wed, Sep 27, 2017 at 5:44 PM, Bruno Haible <[email protected]> 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/
