From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4639 invoked from network); 1 Jul 2023 23:06:52 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Jul 2023 23:06:52 -0000 Received: (qmail 16081 invoked by uid 550); 1 Jul 2023 23:06:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16016 invoked from network); 1 Jul 2023 23:06:47 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu CB8CD3C02213D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1688252795; bh=ibULZz4pTrFKBqTg2yMNvGFnfxNW1ou9HfNTuSKXD2U=; h=Message-ID:Date:MIME-Version:To:From; b=OCpTsXkOmDbMGtpaB2pDFI6pw84hPc5Yn0i7s2eF8TVKQugqZXrfel7Bkp8Hz53Vo wIZj2QV95PoY9ZJ+Oz9Ey3HsjRk0XLuAeckhW6u1BTY17QC8bCB6MlV2ure8wkGIiP JjgTJsk176IUQGivlsJI8d4nbxbaWAxVbIIrFS2p+1ky6+oisqTecrpuIfY7lhObRG pRDf3gxuYEPTQ2AGtIy59Wsk6n5Mj3pGKtRwG2zbF/Mu3c/Beii8UKyeANx+c3YGzp 9fNXwI36oYhASncDaHfFG1vxOJiDEkVlCJflAIAA+IknU59ykYbWM328VtP2tjXRSd BAfcOtCcZs+Dw== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Message-ID: <8eb7980c-0d3d-4b6e-95fc-43d570d220a0@cs.ucla.edu> Date: Sat, 1 Jul 2023 16:06:35 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Rich Felker Cc: libc-coord@lists.openwall.com, linux-man@vger.kernel.org, musl@lists.openwall.com, libc-alpha@sourceware.org References: <20230628175329.GA16113@brightrain.aerifal.cx> <20230628191525.GS20050@brightrain.aerifal.cx> <8e65a459-a933-38b4-5f82-f7016c107d91@cs.ucla.edu> <20230630233705.GW4163@brightrain.aerifal.cx> <20230701143205.GX4163@brightrain.aerifal.cx> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20230701143205.GX4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t On 2023-07-01 07:32, Rich Felker wrote: > These are not "new APIs" from the standpoint of glibc, which already > had them in 32-bit-off_t API profiles and can't be expected just to > remove them. That's OK, as the proposed doc change doesn't remove the new APIs. By "new APIs" I meant off_t-oriented APIs newer than the fallout from the LFS mess of the 1990s; these APIs are not that new to people versed with the Linux kernel. > I'm all for using off_t in new interfaces. But unless glibc folks > agree, I am not for redefining interface types in a way that breaks > one of their supported profile The change I just proposed doesn't invalidate any part of the glibc implementation, or of musl for that matter. They're both fine as-is. (The previous doc change - the one that prompted your objection - did invalidate the musl implementation, and that is one thing the proposed change fixes.) Just to be clear, the proposed change is merely trying to document the current situation more carefully, so that programmers who are not expert in this area are better aware about the unlikely gotchas. It doesn't attempt to change or invalidate any existing implementation. > 1. The spec was that apps declare loff_t objects and pass pointers to > those to some of the interfaces. That works on all existing > implementations and profiles. The fact that it worked was merely an accident, as people didn't follow that old spec. None of the apps I know of use loff_t for these APIs. The spec for these APIs should never have suggested using an oddball type like loff_t that actual app code typically doesn't use. The spec should instead suggest working code, code that is what people would or should actually write. The proposed patch does this. > 2. The spec was silently changed to be that apps declare off64_t > objects and pass those instead. This breaks on musl which > intentionally does not have LFS64 types/interfaces. The proposed patch fixes this. > 3. Under your proposal, the spec is that apps declare off_t objects > and pass pointers to those. This produces a pointer type mismatch, > and buffer overflow, if building with glibc and (still default) > _FILE_OFFSET_BITS=32. There's a loud compile-time error if you make such a mistake. It's the came sort of compile-time error you get if you misuse any glibc API by passing a wrong pointer type. If these compile-time errors are good enough for the rest of the glibc API, they're good enough here. > Of course glibc could try to remedy this by somehow masking these > functions when _FILE_OFFSET_BITS=32 so they can't get used. I don't see why that is necessary, or even a good idea. Many (in my experience most) calls to these functions will work fine even with _FILE_OFFSET_BITS=32, because they're passing a null pointer. I don't see why we'd want to prohibit this.