From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KBFp9W12; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 8F1625A0619 for ; Wed, 29 Oct 2025 05:43:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761713003; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x6ZCv8DsQrcAhHpn9GLW5QNPKSX8UjZYOkN6lQRwFpM=; b=KBFp9W12n+lvoFxs1gA1QENScQAyr9viTYXnJCsiBUbzrqMOhWUD2oPBsuDL9IpKG0EQAR AHyD07ikGW0I5Ze/UQRhX94GwI7GVuwRvPrHq+ZsQEJvUee/jGP11pBBSH0edhYFWcqhk1 +6xO0a5mONvii4PlE2IAeFt7T1V7DWo= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-303-pTj0eoF1OLiRPzJSfCGJzw-1; Wed, 29 Oct 2025 00:43:22 -0400 X-MC-Unique: pTj0eoF1OLiRPzJSfCGJzw-1 X-Mimecast-MFC-AGG-ID: pTj0eoF1OLiRPzJSfCGJzw_1761713001 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-46e39567579so36276555e9.0 for ; Tue, 28 Oct 2025 21:43:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761712999; x=1762317799; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=o2VEjnycuxbFy9PHWIYcPTzMW30X590F65usxZaEpK0=; b=sGeVs8UDiocgbvUtDStGDEs54d56UZVarkMK2Awh4Q+278wV+yMWXz0KLqCPKZyOmc hTMq+O/ulooCopfSrhlMouj+B/JvJ6+S4sMpluouqTCW82BFr4mF4iiNfDuSRG+LYqVB AENwGjBjIycghO7cwlQBLDc0wXfzqBq6E02/90jSB5u8Aty8pcuYCcvs4Qo5FRcGuG87 LzWulzDaN5n9lCFLpKjvuKj/D4d7L0J41mTrvivLPp/7ZIGr+rva9VtxlqgQ7JXvofU/ EgafzhPv0hB0v6WxCHW4p7C3RVeWjsYjpyz3I0/ZbYAQmwynWuCFNbH2yzlsPGQYh0BN DzlA== X-Forwarded-Encrypted: i=1; AJvYcCUQMljWzJ638/htV0nUx0Rv/WFZRSfhFdPa7hycyARBrMedkOtQX50NkO0/HGJ5rYlJHPekguK/1wA=@passt.top X-Gm-Message-State: AOJu0YziEOYgL3vFCnGBKJ+bHS1rTHVQ1f+b8oYue/S08AEm6xZhyFvC 7fxiDh4i8wVZNhL6dnew6TJ43sokds5i9W04nm/DxA4AuNZIfZcpP7yCsG54kyxw5d5cvQOoiX5 DgeqkYfXvlXyOR0fsuiLyCeuANTihkAaR1YDIRu1iLo8+UjTp0GEaog== X-Gm-Gg: ASbGncvjVQyR/cj6fO/uMQ0MGesHIGMJlTWKfJgFMNErJ7vaHiihsg9J1JfRou+IPr9 9GVN4i85hheRZTDcIYDvux8zBeKd47rQEamgqD0A+KDrBJOmkdQ5bejGz7kLWwgS2TsUef7gIWE Pdz4CoRrIc2utFZpijPjmTT6Nsa6smtFdD4AL9X06YWU+BrEclFicIVjgY7lnbKtufnVMT6IDFI LvK41mm3y2zbOu19dWor0aDWvcleznOsdn216gZGTSU7rwQqpUhsjWOTpjSgRXLrOuRtDtQCMXN WtbYGLKgamF8jjD/xRrhpazJ8RZPMGbleDdl+Urgu2Z5+dvHBg0tniSQl6IpdJpT58JIhaY/RoP No2mifMF9yA== X-Received: by 2002:a05:600c:3505:b0:471:700:f281 with SMTP id 5b1f17b1804b1-4771e21c7bdmr12693235e9.25.1761712999267; Tue, 28 Oct 2025 21:43:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGH+6fde70o4Yz7bpKz/dC0gyzay4i1WI+4Ah6GBSneNPNQyWkqOPiTO8sDMIpgTFQuajRDXA== X-Received: by 2002:a05:600c:3505:b0:471:700:f281 with SMTP id 5b1f17b1804b1-4771e21c7bdmr12693085e9.25.1761712998721; Tue, 28 Oct 2025 21:43:18 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4771e201eebsm26848785e9.9.2025.10.28.21.43.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 21:43:17 -0700 (PDT) Date: Wed, 29 Oct 2025 05:43:16 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 2/4] util: Introduce read_file() and read_file_long() function Message-ID: <20251029054316.05fe73aa@elisabeth> In-Reply-To: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-3-yuhuang@redhat.com> <20251029001248.09193eb4@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: hk5kA1DS4msIeeozfQG67GKTA0Xwqrrfz6NfnUACdjE_1761713001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 73PQFS4GKURD6NJDX2X3IJZ74MP5R2NO X-Message-ID-Hash: 73PQFS4GKURD6NJDX2X3IJZ74MP5R2NO X-MailFrom: sbrivio@redhat.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: Yumei Huang , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 29 Oct 2025 11:43:00 +1100 David Gibson wrote: > On Wed, Oct 29, 2025 at 12:12:48AM +0100, Stefano Brivio wrote: > > On Wed, 15 Oct 2025 15:46:12 +1100 > > David Gibson wrote: > > =20 > > > On Wed, Oct 15, 2025 at 11:50:53AM +0800, Yumei Huang wrote: =20 > > > > On Wed, Oct 15, 2025 at 7:28=E2=80=AFAM David Gibson > > > > wrote: =20 > > > > > On Tue, Oct 14, 2025 at 03:38:34PM +0800, Yumei Huang wrote: = =20 > > > > > > Signed-off-by: Yumei Huang =20 > > > [snip] =20 > > > > > > + * @path: Path to the sysctl file > > > > > > + * @fallback: Default value if file can't be read > > > > > > + * > > > > > > + * Return: Parameter value, fallback on failure > > > > > > +*/ > > > > > > +long read_file_long(const char *path, long fallback) > > > > > > +{ > > > > > > + char buf[32]; =20 > > > > > > > > > > Rather than just using a semi-arbitrary 32 here, I'd suggest defi= ning > > > > > a new constant similar to UINT16_STRLEN. Except that's trickier = for a > > > > > type that doesn't have a known fixed width. Pity the C library > > > > > doesn't have constants for these AFAICT. =20 > > > >=20 > > > > I will just define a UINTMAX_STRLEN with (sizeof("2147483647")). = =20 > > >=20 > > > That's not quite right. > > > - It should be INTMAX_STRLEN (signed), UINTMAX would be for the > > > unsigned version > > > - That assumes intmax_t is 32-bit which is probably not the case (it > > > will be 64-bit, maybe even 128-bit on modern systems) > > > - For signed cases, it's the minimum (negative) value that gives the > > > longest possible string (for 32-bit, "-2147483648") =20 > >=20 > > By the way, while it doesn't cover intmax_t explicitly, I think this is > > a pretty good resource as it covers most architectures supported by the > > Linux kernel (hence, most architectures we support): > >=20 > > https://wiki.debian.org/ArchitectureSpecificsMemo#Summary =20 >=20 > Oh, nice, that is a very handy resource. >=20 > > and judging from intmax_t(3type) I'd say that the sizeof(long double) > > column tells you how big intmax_t is. =20 >=20 > > Well, at least, that's the page I use to know which architectures I can > > use to check things when I suspect a type portability bug. > >=20 > > That's because 'long double' should always be the biggest "native" data > > type, that is, excluding __int128 or vectorised / SIMD types such as > > __m256i. =20 >=20 > This part isn't true, alas. Theoretically speaking there's not > necessarily any relation between the largest native integer type and > the largest native float type. Oops, yes, I misread intmax_t(3type), that's *integer* only (of course, the name says it). So probably it has to match sizeof(long long)? > But more importantly, it's not true in practice: according to the > table sizeof(long double) is 16 for amd64, but sizeof(intmax_t) is 8 > empirically. >=20 > I think sizeof(long long) is more likely to match sizeof(intmax_t), > but I don't love relying on it. Right... well, about relying on it, without a change in the C11 standard, can it ever differ? I don't think so. We could have a look at C17 / C23 and if long long is still the largest integer type, we know we're fine for quite a few years / pretty much forever. By the way, just as a reminder (also to self): we don't actually need this here. --=20 Stefano