From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ll0XJY29R2oIwCMAWB0awg (envelope-from ) for ; Fri, 03 Jul 2026 09:47:57 -0400 Received: by simark.ca (Postfix, from userid 112) id 877521E098; Fri, 03 Jul 2026 09:47:57 -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 [38.145.34.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 D75141E024 for ; Fri, 03 Jul 2026 09:47:56 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 637AF4BA23C7 for ; Fri, 3 Jul 2026 13:47:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 637AF4BA23C7 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id A30E64BA543C for ; Fri, 3 Jul 2026 13:47:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A30E64BA543C 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 A30E64BA543C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783086453; cv=none; b=nIBSPoy8B2i7Cnc2neNQsFNsNPalu0ypAZ98oyl6ddaLU05WM8Mn1SFQJEhlKS3n3AqMwLMiqhHHG5dHkDLESy+UwK0jZbm4fDxW9pjhv6ZPwzK6DeMKnqjVeFXaInYK21vPZm+oyztm9N5REVry8vy+95UvPXyeg4F9HMrAO68= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783086453; c=relaxed/simple; bh=0w1KxGA6DL2lpl+qe7Li2J4LYZJrtMKhBBWh2Zskcps=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=nhx2bFe2yJeoPGnOMJycRxq6SelgJPL2yBXlG4t1P1li76Hp64abCVhgQMuBsGgnrTOTyGkjGCBiJ/XUJqay141y+E3ro2nJNtpK3gwW1XXTNP4vlriXih2LBumWn3gt5bFri54rOAnxoj0KIBNQI93Vcbl2fg+yibxApmY7zdI= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A30E64BA543C Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49241dbf9c1so4703115e9.2 for ; Fri, 03 Jul 2026 06:47:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783086452; x=1783691252; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Fi+GJnNQOU5fOWA5Z6wH2tqoI1x5X4jx+C2d7IN0Cj8=; b=lCgkjumRk+68kZheTsfXIhIB8PjnIaNvVUX9ZjbBrYGPBwPS569wkfYRZpHXevJX39 AlFeiCTUXpgghCrYSZfDLfiikxbmPDvlF1PFhxzARZBIMqtd/KC1JmaSwE3mcocCDuN2 6PdjGMTb3TSsQSdZ3+1SkArQKoLOmyFeTZYulz2pHFjJrMNBRHO9+SNQ2Yl3Oqd+dUWD QBD7gIjaqQayr2ja9Y6BkWkzpN2b+Ib6mvheMdVrgqQnZ44Z9ydfqmRuXCzXJGYQ0Qwv 1JiQ43AM23s5ykVl0y6Nqc0E93JhvrO5HJA71D6DpT05TbeGF3Hmokdlcz/rt2qD8Plc WyyQ== X-Forwarded-Encrypted: i=1; AFNElJ+quaxs3mHDEF9tY18busogFCyqy8TfK4WGPqggp22hZtt6ifbB1NLIre415oRz1cON5+DvEwRY+u3B9Q==@sourceware.org X-Gm-Message-State: AOJu0Yz9AMnDsG5HBpRB39Wz+/7+z/lmZ3M9MV0ANRHMaRlA5G9fgA0X mExyRWtCb6oHXviclyqy2kg7x8jP5FNH0K59P7EEHcA4wc03f38OwurV X-Gm-Gg: AfdE7cnCDlS6aMS7Xc7NX0rnsDL7Ag5oyo6UixrREVMyRhiS146UO5zA6DsIjnJDh2+ qqvvV2s3we0cXUdgAoOnvLp1wXGaldEZ3+4dHWioa8R997iUnt3r2cYyGOIdnHljKbulj63oLd/ 9XiQklVubmECObHZxR8lhrUZKmrsNnOlmGCwOozTa73T6eewvv9hHg8yZIgPe7ZzZFDjFodZNgC oj992boUr9QmiIme1e7FIqsMs7FalyNxhSkI1D88XyEuWpPtcqgKfuJAhDuV9bGCbXavuoAFfp1 JfbuzQHf9KiL+s9y18TlHLqwQPJWkcwqr1yllrR3TgbOTOpqMRqxxpEYSpcz5xozkFLziRBT2ny wz2hGBtW5ztlQbVfHTyMSUHqWVlhsX7ZUJtFS+2qT0y+Wyu6mufjsVINod4a/7x0ZEgJ+q/1rmM RVoO9UhbiIT9AkPm18so3y9YDH0UaaLIzH0ljGztuNwOWtvBwZsDw6EbQ= X-Received: by 2002:a05:600c:15d5:b0:493:c337:db1a with SMTP id 5b1f17b1804b1-493c3dfc5bemr85011425e9.38.1783086451884; Fri, 03 Jul 2026 06:47:31 -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 5b1f17b1804b1-493c636e9e9sm129052775e9.2.2026.07.03.06.47.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2026 06:47:31 -0700 (PDT) Message-ID: <20854a3f-d7ab-4fdb-b694-a12a16315de0@palves.net> Date: Fri, 3 Jul 2026 14:47:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, amd-dbgapi-target: use PRIu64 and PRIu32 To: Tom Tromey , Lancelot SIX Cc: 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> From: Pedro Alves Content-Language: en-US In-Reply-To: <87echlf8s5.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-02 21:15, Tom Tromey wrote: >>>>>> Lancelot SIX writes: > >> Hi, >> Doesn't GDB have an implicit habit/policy not to use the PRI??? macros? > >> I do not mind them in amd-dbgapi-target.c, but want to make sure >> global maintainers are fine with this. > >> I guess the alternative is to use pulongest + %s instead of PRIu64. > >> i.e. something like this: > >> str += (agent_id != AMD_DBGAPI_AGENT_NONE >> ? string_printf (" %s", pulongest (agent_id.handle)) >> : "?"); > > I don't know if it's a policy exactly, but personally I prefer pulongest > et al, since I find the PRI* macros pretty ugly and unreadable. Agreed. And it's also a portability hazard, like other printf formats, as you have to match the printf format to the type of the variable. For typedefs, you have to either hardcode the underlying type (as here) when it's supposed to be an implementation detail, or add new PRI-like macros for the typedefs. The pulongest (and paddress, etc.) pattern mostly eliminates that, as the printf format is always "%s", at a small runtime cost. (std::cout << ... << ... tends to be unreadable too IMHO, but we don't use that, thankfully). {fmt} would be better, but that's either a new external dependency, or bump to c++20 for std::format, or c++23 for widely available std::print. Pedro Alves