From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 994A83858D28 for ; Tue, 13 Sep 2022 18:47:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 994A83858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9BB13160088; Tue, 13 Sep 2022 11:47:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id S25hPDf7e-co; Tue, 13 Sep 2022 11:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5B0D416008E; Tue, 13 Sep 2022 11:47:01 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 5B0D416008E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1663094821; bh=3a0nbo0TKUP1BjF+fw9n1bh8IL3feEQsZxZJqyHm6PQ=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=D8nIdR7E4CncOXHWTZkO6YBb+/qMqIZXBfn4Nrpr9d33NFS7h2A+8CsCHtHTNk19/ 4plW8h8oaWOpWEyC8igogfGDXh8x/OFNhU9mS4Fg26/dIHknWOU6Zg7b3li14jLG+M go4uGcRq6rM/NvlkbeJFu7w87Fo4+3TtZp81Q+4M= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ow0f6i8Frmx2; Tue, 13 Sep 2022 11:47:01 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-2-24.fv.ks.cox.net [72.206.2.24]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D2F57160088; Tue, 13 Sep 2022 11:47:00 -0700 (PDT) Message-ID: Date: Tue, 13 Sep 2022 13:47:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] inttypes.h: imaxabs(3): Implement as a macro Content-Language: en-US To: Joseph Myers Cc: Florian Weimer , libc-alpha@sourceware.org, JeanHeyd Meneide , Alex Colomar References: <20220913151853.153311-1-alx.manpages@gmail.com> From: Paul Eggert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,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 9/13/22 13:27, Joseph Myers wrote: > C2x allows integer types wider than intmax_t in certain cases.... > (Changing intmax_t would be a pain because of the very large > number of printf-like functions in glibc, all of whose ABIs involve > intmax_t.) It would indeed be a pain. However, the possibility of=20 wider-than-intmax_t types is potentially even a much greater pain for=20 user code. It's common, for example, for user code to have functions=20 like this: =C2=A0 int =C2=A0 print_offset (off_t offset) =C2=A0 { =C2=A0=C2=A0=C2=A0 intmax_t off =3D offset; =C2=A0=C2=A0=C2=A0 return printf ("%jd", off); =C2=A0 } Unfortunately, code like this would not work if off_t were wider than=20 intmax_t. This is fresh in my mind as I recently added code like the=20 above to paxutils, replacing older, pre-C99 code that converted off_t to=20 strings by hand. Was I mistaken?=20 Is it safe to assume that standard types like off_t are no wider than=20 intmax_t? If so, this should be documented explicitly somewhere in the=20 glibc manual. If not, user code would be in so much hurt that it really=20 ought to be glibc's job to widen intmax_t to be at least as wide as=20 standard types, as painful as that widening might be.