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=dPnTrNrP; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id AF0C15A026F for ; Wed, 29 Oct 2025 17:23:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761754999; 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=odEUPCsvMdMZOaiO79R9njsV3i93D1NkqGL/K7OivzA=; b=dPnTrNrPFqrMUCCYg0/dctyY0sp2do4LrXNEQmwS1gtEkdN7WTHyrOny9yfH0kXLJ27voN jGJ2ezfgefj0La8n3gNBZN+PC+LM7zkgH4zl50rcidzFu0pGJB37x57wEriAB4QssyaI15 s4SASbsAiFVDPIwqgC2AoO8Xdhf7BoM= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-656-FBtROPLPO9KwymdMF2Uqcw-1; Wed, 29 Oct 2025 12:23:18 -0400 X-MC-Unique: FBtROPLPO9KwymdMF2Uqcw-1 X-Mimecast-MFC-AGG-ID: FBtROPLPO9KwymdMF2Uqcw_1761754997 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3ece0fd841cso23697f8f.0 for ; Wed, 29 Oct 2025 09:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761754996; x=1762359796; 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=odEUPCsvMdMZOaiO79R9njsV3i93D1NkqGL/K7OivzA=; b=xMCmNMvCTXAXX0Na/fl01DwPDwT3Q7yF4yaaO3iaOuRnXO+Teny6JaZMNvQkrZuBHs b6hcHqY1azfradtmoK4MZv96793HYGGn6PdLnjxZFDFkFifwju9JYm8PDdvi3hmB2R6X rgvAhsL72iZsr38xZ660KOg/ku0F4pYu71eBgVM4iLPx4Pp2b1bw4O5rKEw/7FqimQBg ViGGCNfffBH1mue3Ydv1L1ZtgxYI9w6mggYQVX0TRmcnp4BdTS3aWrEN4woaF350gEZL KAikCphHC662+lXdp23bMJ5BDPEKQlbXVxia78BAaWPflQuJIDNrbo3I9Q9no6hRzYVy 554Q== X-Forwarded-Encrypted: i=1; AJvYcCUTE7FbKKjiZTuYNJ1ch6D4fMhzDln3dhMjmPyObe8UFDOkhc1gjX5/SfgC8H3cx77uC/NHkeD4p5Y=@passt.top X-Gm-Message-State: AOJu0Yzd5jb9wNwKdzHgDe+uvTfDnuXjJC4Juzy2pFoq6s5aY00QeVot +jmH7sfaCT6ELZXDlLAMOf383ePkuw4Zcc1QYJnU51VM/ndyHxTWv9W7dMUUsDLfeav5GYg71KD TD1qHWts7Xq51kkGnIBOAjpc6WvhpRBVOcHsQRDz03yWFMnCSO2QskMYHF++zzA== X-Gm-Gg: ASbGncuIdea4IHa8xjHmtFz9XmT6AhBtHa4fpQ2d6kSXEoOfRt7T5620o+Tcz5RjJLW vJH+XXUUueL8ixhFobZyQygw2ao2VEaQh+Uk0oexV/F69eU5DwEI7a+25Y/mK4l7iWNvb9NJLrT xgmka/mype91sk0CUvnDaKUDR5g7r55pShaVTgFlK/bC/AHYoGVPVsifJAGUFlYeuig59zQvUh9 tLEZANbx25wAdbDNWUO0/URY99JkXFfhTBXaLdO0ri8nbs0iwT28pgCIKjU/rz+BGaszr9sA5uC Jx97TMIjD0tXM56HxGd4tAlF3CM0tAq5G0AgIA5/cPJqoJ/ibpHjDJtiwr3LAE+l+GBg93+zJkl qhlp2rhTFBTybJ1QJ95zszaRE6uo= X-Received: by 2002:a05:6000:480b:b0:428:55c3:ced3 with SMTP id ffacd0b85a97d-429aef77da6mr2473327f8f.1.1761754996438; Wed, 29 Oct 2025 09:23:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEi4690bPo8JVuetL8xrBLWqTr5/s1U7fKvMqrkLqU6wx1NFz3Agwb6qro50UIJrUh2TDBVLQ== X-Received: by 2002:a05:6000:480b:b0:428:55c3:ced3 with SMTP id ffacd0b85a97d-429aef77da6mr2473303f8f.1.1761754995933; Wed, 29 Oct 2025 09:23:15 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-429952df682sm26920238f8f.43.2025.10.29.09.23.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Oct 2025 09:23:14 -0700 (PDT) Date: Wed, 29 Oct 2025 17:23:13 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 2/4] util: Introduce read_file() and read_file_long() function Message-ID: <20251029172313.2e7b51e0@elisabeth> In-Reply-To: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-3-yuhuang@redhat.com> <20251029001248.09193eb4@elisabeth> <20251029054316.05fe73aa@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: hb1eUPrhK1xQDuh8oP5SCSSRi7SKKjh6_6yJYRIuQek_1761754997 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MRMLMD7SDJU75BTJH4RSCQ5BPG7SX2IF X-Message-ID-Hash: MRMLMD7SDJU75BTJH4RSCQ5BPG7SX2IF 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 20:35:08 +1100 David Gibson wrote: > On Wed, Oct 29, 2025 at 05:43:16AM +0100, Stefano Brivio wrote: > > 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: > [snip] > > > > 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 > > > > > > Oh, nice, that is a very handy resource. > > > > > > > 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. > > > > > > 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. > > > > > > 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. > > Uh.. maybe? I'm never clear on what's guaranteed by the C standard > and what's left to the platform / ABI. AIUI the reason for intmax_t's > existence is because an awful lot is not pinned down by the standard. The standard specifies long long, without a width, and not long long long, so we know that long long is the longest we can have at the moment. > __int128 does appear to be a thing that is longer than long long. Yes but that's what I meant by "native" type, for lack of a better name. It looks like they're more commonly called "main" types instead. __int128 is a GNU extension and specifies a 128-bit width just like __m256i specifies a 256-bit width. Those can be bigger than intmax_t. > Maybe there's a rule that doesn't allow intmax_t to be __int128, but > I'm not sure where we'd find it. No real rule but BUGS in intmax_t(3type) reports this (even though it doesn't look like a bug to me). -- Stefano