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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4432 invoked from network); 1 Jul 2023 23:03:10 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Jul 2023 23:03:10 -0000 Received: (qmail 12178 invoked by uid 550); 1 Jul 2023 23:03:03 -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 12116 invoked from network); 1 Jul 2023 23:03:02 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 3B2D13C02213D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1688252570; bh=gNgJUjk+lxbUNoQmgNdwo8nuZs4gFTCjKlXTFnyIsRg=; h=Message-ID:Date:MIME-Version:To:From; b=i2hRUX2J1pQRlHr0XUJbVcu/QPggVSelIwRgyb05ZvVT/Ty3eNKT7LNcEq4V8s/7h 7eBXIzAbGOl1UVrNkNZURAcIMrqXJ3guaqJlecM8xh92G2omRNmc0t+oMwz0B8knUb OSQQMxq/ncs0UC+G5qSLfdjFGVYnYqc/r9LTsSzGuP7kCIf0qO1bcS1p24gCH/iVVp DtgA1EMqvwYvQmT0gvpLqU+m69htUV8/Mr+NrcBpYR/zkYY8YILH+lQPggTbN4sOtX ge8FBKtrOY1+QsG6j6al1e2mQbH2PFZYSkMmeY6eLMwEIY0vSwCfSEZqGlorM7IH1a JnnX1jRunasYA== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Message-ID: <574389bd-7481-7192-d1ba-f4e62e34c358@cs.ucla.edu> Date: Sat, 1 Jul 2023 16:02:49 -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: 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> <20230701133652.GF3630668@port70.net> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20230701133652.GF3630668@port70.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t On 2023-07-01 06:36, Szabolcs Nagy wrote: > loff_t * can be incompatible with off64_t * as well as off_t *. loff_t * cannot be incompatible with the off64_t in the current implementation. The same goes for off_t, if you compile with _FILE_OFFSET_BITS set to 64. As you suggest, a future implementation might change this. But if anything this strengthens the case for the documentation avoiding these pseudo-off_t types, as they're less stable. > the documentation change can break the api of an implementation, > it is not weakening the spec. Are you talking about the doc change from loff_t to off64_t? If so, I agree that change invalidated the musl implementation. When I wrote "I don't see any incompatibility with glibc and the changes I proposed" I was talking about the patch proposed here: https://lore.kernel.org/linux-man/31b53a8d-7cf4-b3a3-371f-a5723963383e@cs.ucla.edu/2-0001-off64_t-prefer-off_t-for-splice-etc.patch As far as I can see, this proposed patch doesn't invalidate any implementation. If it does invalidate one could you please give an example call that follows the rules of the proposed patch but does not work on glibc or on musl?