From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id C5E073858D1E for ; Sat, 8 Apr 2023 22:05:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5E073858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7E4CB3C09FA04; Sat, 8 Apr 2023 15:05:41 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tHQY9Qgl45q1; Sat, 8 Apr 2023 15:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 16E8F3C09FA05; Sat, 8 Apr 2023 15:05:41 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 16E8F3C09FA05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1680991541; bh=ZuweHPqKBUr/iHFlclW+Fatl2lfFAkQV1KWuQzCnTEg=; h=Message-ID:Date:MIME-Version:From:To; b=gHgXv1I/KxBQYzHoqO3Hhzrrk/6Ddlrco2jn+GFM0JZEFbV3bkhInDazI4BOuZrXj Xm2punAOSDVK4tiEvDwVIcbDMHLJSeVMz7SDZN68sY48ZFPjnFSyI9u0OcelaQn0gW fq8Wo3/dME8O6dVHQP/yZo4M+eDHbQH3mcoVRQxF51gE+yChVt+XEWFJmienxyBRl7 2mWjZQOdoQUKTLy1n2Y0v2Hv7SqZ6Gpu96ntl0k5iEYSdvuEkj0A+VSNkLNTWTw7rL 0mge7LikNUJV9vrH5XGLIXFZNx+AMebVjfh1+pRyXTJhbpoI9FAd5uRQSEtcyEYjgX uE9KUSJGsW5qg== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pewMlgsTX3_s; Sat, 8 Apr 2023 15:05:41 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id E8B3B3C09FA04; Sat, 8 Apr 2023 15:05:40 -0700 (PDT) Message-ID: <5df7f354-f571-d358-5d66-46f02f70e0d1@cs.ucla.edu> Date: Sat, 8 Apr 2023 15:05:38 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 From: Paul Eggert To: Florian Weimer References: Content-Language: en-US Organization: UCLA Computer Science Department Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 0/2] strlcpy/strlcat/wcslcpy/wcscat implementation In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 4/5/23 04:20, Florian Weimer wrote: > Paul, the Austin Groups issue you raised has been closed. Do you keep > your sustained objection to adding these functions to glibc? Yes, I'll withdraw that objection if we add the functions in a good way. Compatibility with POSIX is more important than omitting a misguided API, so long as the harm is limited to people who insist on using the API despite being warned. By "good way" I mean the following three things. 1. Fix the manual to agree with draft POSIX (currently it disagrees). Also, the manual should mention the same sort of problems for strlcpy/etc. that it already mentions for strncpy/etc. - truncation can lead to security problems, non-text strings, that sort of thing. 2. Do not implement these functions via memcpy or strnlen or anything like that. Just use simple code like OpenBSD's. Preferably just use OpenBSD code as-is. Otherwise we have the danger of straying from OpenBSD semantics. This danger is already present in the proposed patches, which have undefined behavior in rare cases where OpenBSD's behavior is well-defined and where draft POSIX specifies the OpenBSD behavior. We don't have time to formally verify or otherwise carefully audit this code, so this is no place to bikeshed or optimize. The goal is compatibility, not speed. Besides, strlcpy destinations and sources are almost always small, so in practice using memcpy etc. will likely be slower than just doing things the OpenBSD way. 3. The patch should be more conservative: it should declare these functions in string.h only on user request, i.e., only when compiled with -D_XOPEN_SOURCE=800 (or -D_POSIX_C_SOURCE=2023mmL) without -D_GNU_SOURCE. (We can add a new _STRLCPY_SOURCE macro too if that would be helpful, to selectively make these new functions visible.) This will suffice for POSIX conformance, and it will help avoid bugs when existing applications that already supply their own slightly-different strlcpy substitutes are compiled with new glibc: it will give these apps' maintainers the ability to decide after their own manual inspection whether and when to switch to glibc's strlcpy. I'll follow up with more detailed comments on individual patches. And I'll volunteer to do (1), which is likely the most work anyway. I've already done much of (1) and will attach that to my detailed comments.