copying a string with truncation (was: [PATCH] resolv: add IPv6 support to inet_net_pton())
Sam James
sam@gentoo.org
Fri Dec 23 06:55:09 GMT 2022
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 358 bytes
Desc: Message signed with OpenPGP
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20221223/bdee6f2b/attachment.sig>
More information about the Libc-alpha
mailing list