> On 22 Dec 2022, at 20:25, Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> wrote:
> 
> On 12/22/22 19:28, Alejandro Colomar wrote:>> 1) Use strncpy() instead of strlcpy()
>> Would someone please add a function to glibc that truncates a string, while still producing a string (as opposed to a null-padded fixed-width character sequence)?
>> Here goes an extract of the yet-unreleased strncpy(3) manual page from the Linux man-pages master branch:
>> DESCRIPTION
>>        These functions copy the string pointed to by src  into  a  null‐padded
>>        character sequence at the fixed‐width buffer pointed to by dst.  If the
>>        destination buffer, limited by its size, isn’t large enough to hold the
>>        copy,  the  resulting character sequence is truncated.  For the differ‐
>>        ence between the two functions, see RETURN VALUE.
>>        An implementation of these functions might be:
>>            char *
>>            stpncpy(char *restrict dst, const char *restrict src, size_t sz)
>>            {
>>                bzero(dst, sz);
>>                return mempcpy(dst, src, strnlen(src, sz));
>>            }
>>            char *
>>            strncpy(char *restrict dst, const char *restrict src, size_t sz)
>>            {
>>                stpncpy(dst, src, sz);
>>                return dst;
>>            }
>>        [...]
>> CAVEATS
>>        The name of these functions is confusing.  These  functions  produce  a
>>        null‐padded character sequence, not a string (see string_copying(7)).
>>        It’s  impossible  to  distinguish truncation by the result of the call,
>>        from a character sequence that just fits the destination buffer;  trun‐
>>        cation  should  be detected by comparing the length of the input string
>>        with the size of the destination buffer.
>> I'll be releasing the a new man-pages version very soon (a week at most), so that this page and also the new string_copying(7) overview are widely available.
> 
> I released a moment ago.  So, I'd suggest either adding strlcpy(3)&strlcat(3) to glibc, or stpecpy(3) (defined here: <http://www.alejandro-colomar.es/src/alx/alx/libstp.git/tree/src/stp/stpe/stpecpy.c>).  Or even both, since each of them serves a purpose: strlcpy(3)&strlcat(3) are for simpler code where performance and truncation are not a concern, and stpecpy(3) does the same but faster with just a few more bytes of code (and detecting truncation is even simpler).
> 

strlcpy and strlcat is in POSIX next (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
in due course, I believe.

See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch a few months ago
but I don't think anything happened with it yet (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).

I'll update a bug with this new information, as well.

Best,
sam