From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id a15bNgQMSGrWICQAWB0awg (envelope-from ) for ; Fri, 03 Jul 2026 15:22:44 -0400 Received: by simark.ca (Postfix, from userid 112) id CC7251E098; Fri, 03 Jul 2026 15:22:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2D8CA1E024 for ; Fri, 03 Jul 2026 15:22:44 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 43BFB4BA2E1D for ; Fri, 3 Jul 2026 19:22:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 43BFB4BA2E1D Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by sourceware.org (Postfix) with ESMTPS id 0B4754BA5439 for ; Fri, 3 Jul 2026 19:22:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B4754BA5439 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0B4754BA5439 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.221.48 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783106540; cv=none; b=M7j7l/68lE4urxqa5RoO5m+Du3X0r/qbXazXDP5gtNuieCxvsaE0twSyM5HO/Nag6ra30/YjJ90DiqwH3gjDNT/SsPFN+UH21zKZQI3cO57sBSQg5Zh6MoVXq8UY0wvlUWzc32g4CI4Sjl65r81+dEwerZa4VOp64mF5q/YbGoc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783106540; c=relaxed/simple; bh=3GDs9JOciA44ye1xKYaw77KaKCi2GeC9qHrtFJTJ6Rs=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=i8rSTgxZn8EBYezF5fy4/I3AruXjo9n3n9C4fNR3H/LhAXAYGEPa1BmAnIbU7Ec8fZcquGHhzYVZ2WgEodisfydMzipP4lA/0kp4tUFxvHoSWmqEJeGsjl6HCN028590qJQtZEAH6dp5WiNABBZD22gvcpjGMvM2ZHMlMFbCQ4g= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B4754BA5439 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-4631679f204so1221784f8f.0 for ; Fri, 03 Jul 2026 12:22:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783106539; x=1783711339; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NiquoXN33bQOViHc46pBikUk2O0tiJ/F9vYDjhLrxCY=; b=ksdDkv89+wH+r6F9l9g0hdEnMgNsPqr9hl+JgYgKLZ32Gjab5CY0WhmyfbaYalAwl7 /wpvYtEVqEkidtCjfgwse13jIxABMvVCsTsCtg2gRU01FGBWOanueFU0iT/04eBsbAHZ DOUYySv0cPm7UOXIIGDLtQ5iwTPp77XBkC2BYVarOZ1RSM3mGCeQDW7oB7FqTaVr50N2 fubCVmMmvj7Odtl/99AqzXS6SdUUzk/8+sxt9noF/u4R4DwWA0sfvh0fvolNbyF+qhuy ww/xvJykP5GHl05SUESV1MWo2u9sR3/OvchsnwToGF29Vc97Rt6PcfISdeEqPCXf6WGZ NAgQ== X-Forwarded-Encrypted: i=1; AHgh+Rr6FtSjfSyBlIvSYvdCD6jrH9HSNbbRJDSBuVz8nBxbGntNCUH+GOdYx764kasYfg6Ec36/WdyF/LkhMg==@sourceware.org X-Gm-Message-State: AOJu0Yx9Kb8LbhKcAxm0ifTqWF8ZQqGMiNmvW8S/5H9BD05yMOrNd9Ie au3dLNcjJyz/ehIH7A4fTK42ymJHffcUIAJDKDfv6CkH4k5PNT+1CUy5 X-Gm-Gg: AfdE7cnX7iIRY2A5/CsNW4gcpdlkCo1BMA9wBq/gOTMLILqDgBL/UXa3dvzIX45KlkN ftRS6uOSYdGNt/26E9nLlSQ/Z4NULV5St7bBtMHEHEfpm8n9PQirgQrtrxCuZ29uvPi/uvdRuX7 IeAtXPEUsiGYpuW+aoDzcwSsJoIl1pzXj6bnmmImZkLpvrE3EWfNgKnHJPeqts5yZj+8P8U0+tG Vz3OzKCnDk/q93clYZLkKTOrqYABrudND1hvwuqJvghKNEAQE7cSH3atPwx1qVeEApgu+ORn3eY IaqeG52VZFD034yF+bzmZaTiyx2poiHF+Fae6kxeQTL2NTtFmkl7cZA7Y/+nalzXHWVqaVyhnaE /g2M8yWbKVhI15YFRq5YM8KTD6cIdSKTYT6zlA1DiGPTX3WWYueTLkVpIXY8C4/xPMR74Elou5B Kc6BUQw6UtRhkELa/gHkolwY4yNE4tP7BEmW9Lm85CfLg6l3AQ4N+ejl0= X-Received: by 2002:a05:6000:4619:b0:472:e43b:5e8c with SMTP id ffacd0b85a97d-47936f19196mr7618733f8f.20.1783106538823; Fri, 03 Jul 2026 12:22:18 -0700 (PDT) Received: from ?IPV6:2001:8a0:fac2:7700:16ec:3248:805b:c97a? ([2001:8a0:fac2:7700:16ec:3248:805b:c97a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa0f213e8sm1359868f8f.34.2026.07.03.12.22.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2026 12:22:18 -0700 (PDT) Message-ID: <6ccbb7f9-3678-4b32-9077-902dacf07c2e@palves.net> Date: Fri, 3 Jul 2026 20:22:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, amd-dbgapi-target: use PRIu64 and PRIu32 From: Pedro Alves To: Tom Tromey Cc: Lancelot SIX , Tankut Baris Aktemur , gdb-patches@sourceware.org References: <20260701142846.2566570-1-tankutbaris.aktemur@amd.com> <6ae6dd2b-9577-4711-a0c8-93663a28e997@amd.com> <87echlf8s5.fsf@tromey.com> <20854a3f-d7ab-4fdb-b694-a12a16315de0@palves.net> <87wlvcgcry.fsf@tromey.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-07-03 20:18, Pedro Alves wrote: > On 2026-07-03 19:15, Tom Tromey wrote: >>>>>>> "Pedro" == Pedro Alves writes: >> >> Pedro> Agreed. And it's also a portability hazard, like other printf >> Pedro> formats, as you have to match the printf format to the type of >> Pedro> the variable. >> >> Yeah, I meant to point this out as well. >> >> For pulongest you really only need to know whether the type is signed; >> and we could easily fix that if we cared to. >> >> Pedro> (std::cout << ... << ... tends to be unreadable too IMHO, but we don't use that, thankfully). >> >> I thought about this for ui_file but meh. It's kind of i18n-unfriendly >> as well. > > Yeah, like, very unfriendly, similar to how ui_out is unfriendly, with the message split > over several calls. > > BTW, we should look into actually doing i18n, like send the .po files to a translation team. > Maybe we can convince one of the new release managers to integrate the flow into the > release process. :-) > > I think Ubuntu had GDB translations at some point. Haven't checked in a long while. > >> >> Pedro> {fmt} would be better, but that's either a new external dependency, or >> Pedro> bump to c++20 for std::format, or c++23 for widely available std::print. >> >> I looked into this but it is also i18n-unfriendly, since as far as I can >> tell it requires you to either give up gettext or give up any sort of >> format checking. For printf this isn't an issue because GCC understands >> that _() is "transparent". >> > > Ah, yeah, if you run the format string via gettext, that returns a runtime string, so > we'd need to use std::vformat, which as you say, loses compile-time checking: > > std::vformat (_("Hello, {0}!"), std::make_format_args (name)); > > But I think we could make it work, with a wrapper, which is what we'd do anyhow to > work with ui_file. But we make the wrapper a template, which itself does the > format checking at compile time. Like: > > template > void > gdb_format (std::format_string f, Args&&... args) > { > std::string s > = std::vformat (gettext (f.get ()), std::make_format_args (args...)); > gdb_stdout->puts (s.c_str ()); > } > > then with: > > gdb_printf ("stopped at {}\n", addr); To be clear, I meant: gdb_format ("stopped at {}\n", addr); Pedro Alves > > the literal "stopped at {}\n" gets bound to the format_string parameter. > format_string's ctor parses the literal and checks placeholders against Args..., at compile > time, and a mismatch results in a compile error. If that compiles successfully, then we > call gettext and use std::vformat without the checking, which we no longer need as it's > already validated when we get there. > > Note, written in email client, completely untested. > >> Also of course switching to fmt would be a colossal effort. > No doubt. Could be incremental, though. >