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.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11954 invoked from network); 1 Jul 2023 13:37:12 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Jul 2023 13:37:12 -0000 Received: (qmail 23589 invoked by uid 550); 1 Jul 2023 13:37:05 -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 22493 invoked from network); 1 Jul 2023 13:37:04 -0000 Date: Sat, 1 Jul 2023 15:36:52 +0200 From: Szabolcs Nagy To: Paul Eggert Cc: libc-coord@lists.openwall.com, Rich Felker , linux-man@vger.kernel.org, musl@lists.openwall.com, libc-alpha@sourceware.org Message-ID: <20230701133652.GF3630668@port70.net> Mail-Followup-To: Paul Eggert , libc-coord@lists.openwall.com, Rich Felker , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t * Paul Eggert [2023-07-01 00:24:27 -0700]: > On 2023-06-30 16:37, Rich Felker wrote: > > This is still changing the documentated signature, which isn't really > > nice, and would not be compatible with glibc unless glibc went out of > > its way to hide those functions when _FILE_OFFSET_BITS is 32. > > I don't see any incompatibility with glibc and the changes I proposed. The > changes merely weaken the spec in the man pages in an area where the spec > should be weakened. glibc is compatible with the spec before it was changed > to use off64_t, it's compatible with the spec now that it uses off64_t, and > it would continue to be compatible with the spec if the proposed changes are > adopted. loff_t * can be incompatible with off64_t * as well as off_t *. the documentation change can break the api of an implementation, it is not weakening the spec. (it can also break abi if loff_t has different abi than off64_t. two integer types can have same range, representation and syscall argument passing abi, but different libc abi and different c++ abi) i don't think you can claim that glibc is compatible either way, as a future target port can define loff_t differently than off64_t.