From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) by sourceware.org (Postfix) with ESMTPS id 9766A3858C83 for ; Thu, 20 Apr 2023 11:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9766A3858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 59641761CFF; Thu, 20 Apr 2023 11:45:07 +0000 (UTC) Received: from pdx1-sub0-mail-a304.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D6FE27615AA; Thu, 20 Apr 2023 11:45:06 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681991106; a=rsa-sha256; cv=none; b=Z+czsNLqgdYT92y2Ivynq241liyw1k06YoadEcUwrjcHuFzKxRV/XCiAgoOsOC5YfBGNRw GuKP3gmvA/WEqWOoQ/wKD/E4S876I1k5lueYwIiXAMgRUm4T1heCJW6KXijqLv6qKENdlo v3EqitiWKr1zoSC2+IyiqCVsHKelkMAzKegMnPVRb9HJJxLB4vhy/56OAHJkCywoEL4uEl cuvrgFOGAb6PY0u+mmyvcSg9/oBBHtgxDh4TNSCf6jWAMb3NmqCHRZRgKd1Hamqjew0fri SMwkpS/YoIF7m1Vnn2klGDGxSzOtLALhKPfrZ9i8SDoHloRMNfHA1swPiE5hoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681991106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Jk1X1J6m+iKxFxufeHM3AhcZ3ND7GI07VjebX9PS+mM=; b=Q1kNdNpaZ1t3m6y5zbzlJlLHV7rUk37PMP/Vo+EthMoQsVwVdHCwvsoTcn3LxvCASZBTwx y1/+A0PriaUE9NLnzCB2kKAj6iA2c+8p8kHfuUUBXhNCKl53ATZtjmGMicsMnhIAtK3W3N 8KxeRIO4rusqQrGEg/RyjTwuy2tGZ4FkaArX1YnBoG3vSLjqKdaMH9jo7ZjqWiP+8K8QTJ iOTzywpNCcDnOkbxkfpc+lIWhU0/JBXWpthoaUXAWNpBx2KrIpPSGoec2SmCvAh+VhcuP9 cVWgcGYMldgdqWaGvQRej4wAhLQwjAj2/GnuL0w5vGZg6ZqE3sOZGoEUB8Sr4A== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-tqw7k; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Fearful-Trouble: 400d37886de9560e_1681991107141_1288066991 X-MC-Loop-Signature: 1681991107141:2732826231 X-MC-Ingress-Time: 1681991107140 Received: from pdx1-sub0-mail-a304.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.127.59.45 (trex/6.7.2); Thu, 20 Apr 2023 11:45:07 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-80.dsl.bell.ca [174.91.45.80]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a304.dreamhost.com (Postfix) with ESMTPSA id 4Q2G6p3LK1z2h; Thu, 20 Apr 2023 04:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681991106; bh=Jk1X1J6m+iKxFxufeHM3AhcZ3ND7GI07VjebX9PS+mM=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=w57N6m2BTytr+mJ8mEfqaxRwacTdU9J+XoMDpSBK9AKDPsGC9cOdTlcdq72cXQOsG riVy2qOQ5dIGLe3n5gJSQDbRqVIImPEBEub31hhebCn+L4co1Ushxdr+QTHea8W+mV Hc688OTsRfwlh6zA5GXgraH9xGikkoBgp05LdsqQ4BVjlbMiWcVFHRWPdzJ+kfPCag j+BCxn56jHpk/ToLDiujV4HRQp9eNCqNq9kO0tpenLBgypKasjUZgUJMIdOtv+Xm9n b/VTMG9le/Z9OrvQOP4iuXlhQ6mp8whqpVXOF5rrSVutm3FDmraxsNZbiXfW473n6t CEvTiwuibjdsA== Message-ID: Date: Thu, 20 Apr 2023 07:45:05 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 1/2] Implement strlcpy and strlcat [BZ #178] Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87ildqesbf.fsf@oldenburg.str.redhat.com> From: Siddhesh Poyarekar In-Reply-To: <87ildqesbf.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-04-20 06:55, Florian Weimer wrote: > * Siddhesh Poyarekar: > >>> index 673cfd7272..0c78ad2539 100644 >>> --- a/include/string.h >>> +++ b/include/string.h >>> @@ -88,6 +88,10 @@ libc_hidden_proto (__stpcpy) >>> # define __stpcpy(dest, src) __builtin_stpcpy (dest, src) >>> #endif >>> libc_hidden_proto (__stpncpy) >>> +extern __typeof (strlcpy) __strlcpy; >>> +libc_hidden_proto (__strlcpy) >>> +extern __typeof (strlcat) __strlcat; >>> +libc_hidden_proto (__strlcat) >>> libc_hidden_proto (__rawmemchr) >>> libc_hidden_proto (__strcasecmp) >>> libc_hidden_proto (__strcasecmp_l) >> >> Do we want to delay doing this until we have an actual internal use of >> these interfaces? > > The *_chk functions need these aliases today. Ack. >>> +__fortify_function size_t >>> +__NTH (strlcat (char *__restrict __dest, const char *__restrict __src, >>> + size_t __n)) >>> +{ >>> + if (__glibc_objsize (__dest) != (size_t) -1 >>> + && (!__builtin_constant_p (__n > __glibc_objsize (__dest)) >>> + || __n > __glibc_objsize (__dest))) >>> + return __strlcat_chk (__dest, __src, __n, __glibc_objsize (__dest)); >>> + return __strlcat_alias (__dest, __src, __n); >>> +} >>> +#endif /* __USE_MISC */ >>> + >> >> Couldn't we use the __glibc_fortify macros here? > > Do you have a concrete proposal? I was just following what we have for > stpncpy and other functions. I don't, but I'll give it a shot. > I don't think it's possible to use the generic macros for > wcslcpy/wcslcat because of the bytes vs wide characters distinction. Hmm, there's __glibc_fortify_n for wide chars which __wcsncpy_chk uses, or have I misunderstood your comment? >>> +size_t >>> +__strlcpy (char *__restrict dest, const char *__restrict src, size_t size) >>> +{ >>> + size_t src_length = strlen (src); >>> + >>> + if (__glibc_unlikely (src_length >= size)) >>> + { >>> + if (size > 0) >>> + { >>> + /* Copy the leading portion of the string. The last >>> + character is subsequently overwritten with the NUL >>> + terminator, but the destination size is usually a >>> + multiple of a small power of two, so writing it twice >>> + should be more efficient than copying an odd number of >>> + bytes. */ >>> + memcpy (dest, src, size); >>> + dest[size - 1] = '\0'; >>> + } >>> + } >>> + else >>> + /* Copy the string and its terminating NUL character. */ >>> + memcpy (dest, src, src_length + 1); >> >> size == 0 is undefined anyway; we return without touching the dest >> because that's convenient for us. OK. > > size == 0 is defined in OpenBSD via snprintf equivalence, but maybe > that's over-interpreting the manual page. Doesn't seem like over-interpreting to me: "The strlcpy() and strlcat() functions copy and concatenate strings with the same input parameters and output result as snprintf(3)" We should probably just pick a lane then (and specify it in the manual), and snprintf equivalence is probably a reasonable take in terms of safety. Thanks, Sid