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=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9726 invoked from network); 30 Jun 2023 07:11:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Jun 2023 07:11:40 -0000 Received: (qmail 13695 invoked by uid 550); 30 Jun 2023 07:11:35 -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 13633 invoked from network); 30 Jun 2023 07:11:34 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 3C1BB3C09FA21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1688109081; bh=zxpMGfMak2e6fPlpd3KfrxdoC1DGm9WDuQgEbnZ5Q7s=; h=Message-ID:Date:MIME-Version:To:From; b=mSGMd7y2mZNXivMym3dWdp6TjHIz09km/lpHKVZ7Fk9cxN3UEyufGNjZsuThu/WvC 6lLHgvA61HGaSycpJSZoNBKtDfyJSe1KZztGrbtrLMM0PheD9AQJ4TKnFOUQjH2sJt dLp3D2KJB27ol7RqH6mKLbOD00ORF6XflI20xry/NXTqejKlICrzWkuPnpYXk236Zo Jt9PiwKiybuDO3v4S0jsD1y3XUh6J251MsfOR3WUlkltpQq27jEHm9piv8MHg+QyZw uJUVXTGf+KKcm3QTbWQfe4QtdYbZjFzig/OK5bqZFlHaKLQpTRusGrw29FEyklODQp aaeFJ909WhMAA== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Message-ID: <8e65a459-a933-38b4-5f82-f7016c107d91@cs.ucla.edu> Date: Fri, 30 Jun 2023 00:11:20 -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: linux-man@vger.kernel.org, musl@lists.openwall.com, libc-alpha@sourceware.org, libc-coord@lists.openwall.com References: <20230628175329.GA16113@brightrain.aerifal.cx> <20230628191525.GS20050@brightrain.aerifal.cx> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20230628191525.GS20050@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [musl] Re: regression in man pages for interfaces using loff_t On 2023-06-28 12:15, Rich Felker wrote: > There's also the problem that off64_t is "exactly 64-bit" which makes > it unsuitable as an interface type for cross-platform functions where > one could imagine the native type being larger (rather horrifying but > possible). Although we won't have files with 2**63 bytes any time soon, this is the best argument for preferring "loff_t" to "off64_t". But come to think of it, it'd be better to document the type simply as "off_t", with a footnote saying the equivalent of "this assumes that on 32-bit glibc platforms you compile with -DFILE_OFFSET_BITS=64 like any sane person would." The intent really is off_t here, and that will remain true even if off_t ever widens past 64 bits. All the apps I know that use the syscalls in question simply pass values that fit in off_t to these functions, and this will work regardless of whether these apps are compiled with 64- or (horrors!) 32-bit off_t. Admittedly the footnote solution would not be perfect, but it's good enough, and it would sidestep the loff_t vs off64_t confusion. > As for why off64_t is not an appropriate type, it's defined by and > associated with the LFS64 summit and the related intefaces, and > governed by them. Using it makes these interfaces non-standardizable, > because no standard is going to adopt a function whose public > interface depends on another optional thing they don't want to > mandate. I don't see why not. For example, POSIX-2018 requires int32_t even though C17 says it's optional. So there's precedent for POSIX adopting a type that's optional elsewhere. Also, to POSIX loff_t is just as optional as off64_t is. glibc defines neither type if the app #defines _POSIX_C_SOURCE as POSIX requires. So from a standardization viewpoint there's no reason to prefer one type over the other. > This is exactly the problem why ISO C is stuck with the > broken and unusable fseek/ftell that take long, and hasn't adopted > fseeko/ftello from POSIX -- their public interfaces use the > POSIX-governed type off_t, and as such, ISO C adopting them without > adopting the whole POSIX off_t is out of the question. I'm not sure what the point is here, as far as standardization goes. Neither ISO C nor POSIX use loff_t, and neither is likely to ever use it: ISO C won't even adopt off_t much less loff_t, and POSIX works just fine with off_t and doesn't need loff_t. (The same goes for off64_t of course.) > As a particular practical concern, applications performing > configure-like tests may use the existence of an off64_t type to > conclude that the LFS64 API is supported on the system they're being > built on. Which apps do that? But anyway this is all moot if we simply document the arguments as off_t with a footnote.