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=WLFOH9T8; 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 4603C5A0619 for ; Wed, 29 Oct 2025 00:12:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761693174; 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=U/QB3hrLY/uCUnd7Ii7E9POWsRebPrEXvmK0+EIv7hw=; b=WLFOH9T8Cwa4wJXI84zuuQwyI8di4adZ9FsDTaSw9qaexg61Iwug0qUfnP+lAYB6xrpo1v i/zF0sVH2T5SzwDniiKpfZjr8gUjYwEroDLxn9hRXwxl8YpVli2G7sS05JxhCwVvJXZ0B+ B/mlWrCPu5PGXbXTNYnV8Ek34bUkT+g= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-587-fEWqybHiOG2rAmHxqydkzQ-1; Tue, 28 Oct 2025 19:12:52 -0400 X-MC-Unique: fEWqybHiOG2rAmHxqydkzQ-1 X-Mimecast-MFC-AGG-ID: fEWqybHiOG2rAmHxqydkzQ_1761693171 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4298b98f376so4465322f8f.3 for ; Tue, 28 Oct 2025 16:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761693170; x=1762297970; 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=jDGY5L+cAhZ5H4UUJxgd13sk/BdyEEtWklks1Rjk38Q=; b=kfxhIzmxCZ2VdcE/O4j+R3LEOevSAAXZqy0zQ9V89c74FI6zD2M3G/Ng92dO3N4Zag IxvieYs8cFsDsBGMUIG0V905eH3To+01G9Ws9F9ljqp/mxZpG9rNtqJYEthryLfbM/wi pkfqHI7Ehqg/uFNdWbvIrQ6Kl64C6HAE6ywc7jNQFNnOakoNP2A+4Ez4boTka0GlXGdk 2Odrd1sLGxGPe54AXJ4hWcFGf5vbJh4szIrtPToBWv74WHczQtB+w9lCs0X0iz3ZmzBg uAo1fwJahykKK6IqaUv2xZ7CGcLSuWqEP+10xltrAZCeczTlTx6QqFBghTBHGVb2LFE4 aRFA== X-Forwarded-Encrypted: i=1; AJvYcCVg2715AVCOt7JkQi9NUiTYLGowP3BROMqMPsFpR+l10Zn031RpVWFwkJPW3vRJGx6eeoMsw+juMA4=@passt.top X-Gm-Message-State: AOJu0YwTNub4GDp/XxcXOA0hzPp6bdT45Q7hNKFMIwNI8P/HF/wx3wlw fIuQyaqTNRUfECzvoH6B8legPG7EUspKMYiVTI0QQEB+J+QnuerwI7VmITWWdVCqCBarHAKRf1r EzhY4OirB0bUMFmbUE2KCnT5seK3t5pKnP+/lOA1W6tRanO6y5QPRBQ== X-Gm-Gg: ASbGncvf7ttXB1mZcuF/6bS1s3hLZyzp4DJrshJVM1rsOQDJ4fay6eMXfLhrcVplSv5 TpRcOHhrdRZrhFoMp2MuFP3oIeyg09rugxo5LwFwbG8sRN8AuED9NkJLQCbm9JfS11MGFQJh22s fV4dWL110TOK70xjw7SqH3Va4szh7CTQh5JTYpM4PFDshWmwX/hGM9s69O3gzsnACdqW2TDrYRP kK1yyqAUL80PIXOwbKuE5j/gWo/lDejYNy60QJfa9tMk+wVNp3m2zmgUlTlQPIfzz49Sn8iDqTQ qtofyVcaObIzQz373Q6CS5h0OMT6ogJPmys//UTlSuUfPYlcSQQa29a0vTKYZbtQV2BlXcm/Wqc S1tbtDJKBig== X-Received: by 2002:a05:6000:25ca:b0:428:4004:8226 with SMTP id ffacd0b85a97d-429aefb2a9dmr448297f8f.34.1761693170508; Tue, 28 Oct 2025 16:12:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEj7W06wHTWKRFeb+CgHhOzt6IwL33xPnSs1umpEgfqentSlag1kS+DdXMcBTgvnDZ44E/jVQ== X-Received: by 2002:a05:6000:25ca:b0:428:4004:8226 with SMTP id ffacd0b85a97d-429aefb2a9dmr448286f8f.34.1761693170071; Tue, 28 Oct 2025 16:12:50 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-429952cbb20sm22703401f8f.18.2025.10.28.16.12.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 16:12:49 -0700 (PDT) Date: Wed, 29 Oct 2025 00:12:48 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 2/4] util: Introduce read_file() and read_file_long() function Message-ID: <20251029001248.09193eb4@elisabeth> In-Reply-To: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-3-yuhuang@redhat.com> 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: 8iu7BF6_BgHlliIFvTvQK8nzS9I09aLRSUFJKEYXaMc_1761693171 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 3WOOGVXI53RLSQ63DPINQZCW43UMIYFP X-Message-ID-Hash: 3WOOGVXI53RLSQ63DPINQZCW43UMIYFP 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, 15 Oct 2025 15:46:12 +1100 David Gibson wrote: > On Wed, Oct 15, 2025 at 11:50:53AM +0800, Yumei Huang wrote: > > 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] > > > > + * @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 defining > > > 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") 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): https://wiki.debian.org/ArchitectureSpecificsMemo#Summary and judging from intmax_t(3type) I'd say that the sizeof(long double) column tells you how big intmax_t is. 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. 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 Stefano