From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 396CD3858CD1 for ; Wed, 28 Jun 2023 19:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 396CD3858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=libc.org Date: Wed, 28 Jun 2023 15:28:36 -0400 From: Rich Felker To: Paul Eggert Cc: linux-man@vger.kernel.org, musl@lists.openwall.com, libc-alpha@sourceware.org, libc-coord@lists.openwall.com Subject: Re: [musl] Re: regression in man pages for interfaces using loff_t Message-ID: <20230628192836.GV4163@brightrain.aerifal.cx> References: <20230628175329.GA16113@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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 Wed, Jun 28, 2023 at 11:21:39AM -0700, Paul Eggert wrote: > On 2023-06-28 10:53, Rich Felker wrote: > >The whole reason loff_t exists is to avoid this problem and make a > >type that's "always full width offset, regardless of _FILE_OFFSET_BITS > >or _LARGEFILE64_SOURCE" to match with the kernel expectation for these > >interfaces. > > Why can't off64_t be that type, as it is in glibc? I'm not seeing > why we need two names for the same type. And to clarify one thing: nothing glibc is doing is wrong. It's fine for glibc to define the function using off64_t as long as glibc's underlying definitions of off64_t and loff_t are the same type. This still matches the published documentation that says loff_t. I'm not asking for any change by glibc here, just a revert to the man page change which put a glibc implementation-detail in place of the equivalent prior-documented public interface. Rich