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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9906 invoked from network); 4 Aug 2023 16:07:04 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2023 16:07:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5734D42442; Sat, 5 Aug 2023 02:06:59 +1000 (AEST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by minnie.tuhs.org (Postfix) with ESMTPS id 530E042441 for ; Sat, 5 Aug 2023 02:06:53 +1000 (AEST) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2b9e6cc93c6so35172441fa.2 for ; Fri, 04 Aug 2023 09:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691165211; x=1691770011; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qm/qIEVFb26NgI08yAWr2DUP0IQ6KVzHq6eyQjKGHDs=; b=ByCQ52+KXOlZ1HpGJS2Zg5z3rAAC89xibG7t5ZI+9btDBT+rzQJyEDXlBUIIRJNiZh f7eAZT7JeHmW1o3+INFapHRehRy6Ab0jUFpYQ2znSbDXuQ9AeoBngUcYFaH4gLmWJA1Z hWjPUgfEsAu2qWptQX0h88wXfs9EeLItZpDPYqGHtF1V79jI7Xc8z+OS4+KGToxKZeeP QcJ1BuiRfG34jx/pIIAZlYLoIkBR6Y+5mO2FgLpvlhLLUR9CHmkk3/zhbvopLYxixr/s 5ODSrcBPYkn4X9PR7lFZI4bxFqGGqRc6p9aJhdC9f1tn/WVMRgmHguvZV6DrcpuDAnBo 1h5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691165211; x=1691770011; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qm/qIEVFb26NgI08yAWr2DUP0IQ6KVzHq6eyQjKGHDs=; b=HS3t355yVu8EHGbE8PAP6J78X+oqu4B1wZ4oTLboXvs7R4GbbC20d05Vz2Z+vUMyJt qH9kMucEopDm3ouSLTdyymn8/H9auJb6GZxDtfPfbdg1cGj48/68Nd2Av4+UfR4S58X1 UPeQc/xmMHf5pF5gRix7HSTTylJS7v5uVEIdowZBLYID0p9Py0iMRlDhyjZ8bLhXxg4y 2oz7y4vAphNRCLlwqrEorPPG8lmw2Vl7v2U0wjNkxJ+oVVmnrhu0HQqU5o5/ot1F4s55 GuabQxXsUOD9zzmSgYpmzf2ZuH7qCWm+M1RJXGgcjMRLeuDUqiqyf4VBFfTv80mffuxx LUbQ== X-Gm-Message-State: AOJu0Yz6aDMw0PPnAE/63jHHdBRPB3NbkgAEH0z+Gl/68xk9fDw3lPMG LXPszyZkNGy4hqRqe44JsfOVZpxXnxSPWFAUbqF6ZP7y X-Google-Smtp-Source: AGHT+IHvoAwSJuHB2CxrYM09LJ8vtwFrI6Diasm+RYY6fuWImLQ4EI7ertfoYItC41x/l0+IM2Wzfr1It4eBMlTpbsY= X-Received: by 2002:a2e:9a92:0:b0:2b6:eefc:3e4f with SMTP id p18-20020a2e9a92000000b002b6eefc3e4fmr2062267lji.21.1691165211089; Fri, 04 Aug 2023 09:06:51 -0700 (PDT) MIME-Version: 1.0 References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> In-Reply-To: <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> From: Dan Cross Date: Fri, 4 Aug 2023 12:06:14 -0400 Message-ID: To: Alejandro Colomar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: JPI4YRUPUWHMYSEJF2ALVHAOCFFZTYFS X-Message-ID-Hash: JPI4YRUPUWHMYSEJF2ALVHAOCFFZTYFS X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: printf (was: python) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Aug 3, 2023 at 7:55=E2=80=AFPM Alejandro Colomar wrote: > On 2023-08-03 23:29, Dan Cross wrote: > > On Thu, Aug 3, 2023 at 2:05=E2=80=AFPM Alejandro Colomar wrote: > >> On 2023-08-03 19:51, John Cowan wrote: > >>> On Thu, Aug 3, 2023 at 1:29=E2=80=AFPM Alejandro Colomar > >>> wrote: > >>> > >>> But if speed is not a problem, I'd keep the good ol' syntax that > >>> > >>> everybody knows. No need to make everybody learn a "cool" new print > >>>> function, that probably won't be as tunable as printf(3) is. > >>>> > >>>> > >>> By that argument, there would be no C, only Algol 68 and PL/I, or sub= sets > >>> of them. > >>> > >> > >> I didn't claim that there's never a reason to invent new syntax. My c= laim > >> was rather that in this case, there isn't. > >> > >> - printf(3) is more powerful than any other existing formatting funct= ion > >> that I know of any language --I'm still curious of what's the equiv= alent > >> of "%+'0#8.5f" in other formatting functions--. > > > > One issue is that this isn't standard C: the `'` verb for grouping by > > thousands is an SUSv2 extension. I just checked the latest C23 draft, > > and unless I missed it, it doesn't appear to have made it in. > > Being in POSIX.1 it's portable to most (all?) current systems. ISO C > is a baseline for an implementation. A quality implementation will > go beyond that standard (or will be rather useless). POSIX.1 is more > of a useful thing. I don't know that that's true, but I can see how one could get into a "no true Scotsman" fallacy pretty quickly arguing over it. > But yeah, we can remove that "'" to get the idea. > > > But things like that are fairly straight-forward in many other > > languages. For example, in Go, the format string is nearly identical, > > modulo the `'`: > > Yup; I like go in that sense. > > [...] > > > > >> - It is also reasonably fast (at least for such a highly-customizable > >> formatting function), and I'd like to see any system beat that whil= e > >> keeping the customizability. > > > > At Google, a group of exceptionally talented engineers wrote a > > replacement in C++ for both type safety and because, bluntly, `printf` > > (actually `snprintf`) was too slow. I believe the overall mechanism > > made it into ABSL. > > I think you mean absl::StrFormat(). It has printf(3)-like syntax, so > I can't say say much against it. I don't know the details of how they > achieved the claimed 2x ~ 3x performance compared to snprintf(3). I'm > curious to know if it's an inherent limitation of snprintf(3), or if > it's just that glibc is very unoptimized --which is true anyway, because > no-one has really maintained the printf(3) code in a long time--. I don't recall the details now, but I seem to remember that much of it was moving the burden of parsing the formatting directives to compile time (though I may be misremembering). > It's interesting, because then std::format() is not that miraculous > compared to snprintf(3). > > > > >> - It is type-safe, with the right tools. > > > > No it's not, and it really can't be. True, there are linters that can > > try to match up types _if_ the format string is a constant and all the > > arguments are known at e.g. compile time, but C permits one to > > construct the format string at run time (or just select between a > > bunch of variants); the language gives you no tools to enforce type > > safety in a meaningful way once you do that. > > Isn't a variable format string a security vulnerability? Where do you > need it? It _can_ be a security vulnerability, but it doesn't necessarily _need_ to be. If one is careful in how one constructs it, such things can be very safe indeed. As to where one needs it, there are examples like `vsyslog()`, but that's almost besides the point, which is that given that you _can_ do things like that, the language can't really save you by type-checking the arguments to printf; and once varargs are in the mix? Forget about it. - Dan C.