From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailscanner01.zoner.fi (mailscanner01.zoner.fi [84.34.166.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F5EA366548 for ; Mon, 15 Jun 2026 19:26:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=84.34.166.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781551597; cv=none; b=HBbSbMI/bdL2dp6yJ9IBXQrKsxP3D2pQRbGBHreHumT54RIobyBvUz3SoilKuM/HEdRQ6zaOdPLP+VJ47ZMY4RhYDh7goAOegEOMRr5RBjrfmpCdLfKfRSIwoJRibqlNYmlnU+DhtqEcoaorA/s975GDu+lKWKSr0Cg5ALjWgSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781551597; c=relaxed/simple; bh=829/lbvZTxDihq89g2OsEo/Cy4PfyIkQXknyHsmkyC0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aFdtHlzOnTXClg3azPe5Y1R4WfY6JgoK76OjAbwIHtlMsDwRZ4UbQiFIjktA8eLUUX6OvznP2gliKwHMm46CsIRQ2qNsmwU7bf//It+MVI47Ytll7ihkEeGumECu0Wsf6DHsxYbZWEkXczmif3ltK42pYe+XAROQxlqSdgEmBIA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=tukaani.org; spf=pass smtp.mailfrom=tukaani.org; dkim=pass (2048-bit key) header.d=tukaani.org header.i=@tukaani.org header.b=a/jA8vNy; arc=none smtp.client-ip=84.34.166.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=tukaani.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tukaani.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tukaani.org header.i=@tukaani.org header.b="a/jA8vNy" Received: from www25.zoner.fi (www25.zoner.fi [84.34.147.45]) by mailscanner01.zoner.fi (Postfix) with ESMTPS id E496542E6B; Mon, 15 Jun 2026 22:26:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tukaani.org ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID: Content-Description; bh=tDRRzq62Avx9WzOAT3rSeaewq2KcxlaYJUrE1hiwR1g=; b=a/jA8 vNyICImmnPuVI+Zb+kFY3gR+uE83VMdwjFVY7qEhb9mdGAyUFGI/Z8aOaAkocPN07+te5MkehEw/o /LftKGedwSbxwUef3SuEb+uN3jdsAz+1H0yUdflv0U3wNTwXrcja9oDZyPqWhv2qAhq2M9LFHj7rc yTCJTGwK3vGOn9RCHryKYtMxJfpbCNCBvj5RwhJ77/7yNdnw+iWYM7pOzn6Gu5EAq1tGBCyulLd0t qaOBDRY4WgquN/4oDi8XcNSYXqWrvRQULayBwb3J11tyDufzcBu6xylmFKmautsMYH/i/BKmqZxuG Sy8wmt0CP0kyBpTGAjfFzXB10y3HQ==; Received: from mail.zoner.fi ([84.34.147.244]) by www25.zoner.fi with esmtp (Exim 4.99.4) (envelope-from ) id 1wZCx0-00000001Vco-3CSj; Mon, 15 Jun 2026 22:26:26 +0300 Date: Mon, 15 Jun 2026 22:26:26 +0300 From: Lasse Collin To: David Laight Cc: Andrew Morton , linux-kernel@vger.kernel.org, Nathan Chancellor , Thorsten Blum Subject: Re: [PATCH 1/2] lib/xz: Use size_t instead of uint32_t in a few places Message-ID: <20260615222626.26033be0.lasse.collin@tukaani.org> In-Reply-To: <20260615094339.4e2a1dcb@pumpkin> References: <20260614160521.924710-1-lasse.collin@tukaani.org> <20260615094339.4e2a1dcb@pumpkin> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On 2026-06-15 David Laight wrote: > On Sun, 14 Jun 2026 19:05:17 +0300 > Lasse Collin wrote: > > @@ -1046,25 +1048,23 @@ enum xz_ret xz_dec_lzma2_run(struct xz_dec_lzma2 *s, struct xz_buf *b) > > > > case SEQ_UNCOMPRESSED_1: > > s->lzma2.uncompressed > > - += (uint32_t)b->in[b->in_pos++] << 8; > > + += (size_t)b->in[b->in_pos++] << 8; > > The type of that casts can't matter. > Indeed all these casts can be deleted. > (The value read from the uint8_t variable is promoted to int before > it is used.) It is true that the casts aren't mandatory here. There are a few more similar casts in lib/xz. I dislike that narrow unsigned types are promoted to signed int in C; I would prefer unsigned staying unsigned. If the result doesn't fit into the original unsigned type, it feels clearest to cast to the unsigned target type, skipping the intermediate signed type and the need to verify that the signed type indeed works correctly in the particular expression. This results in a few seemingly useless casts, but it's less mental load to think about two types instead of three. uint8_t b = 0x80; uint32_t x = b << 8; // (1) uint32_t y = b << 24; // (2) size_t z = b << 24; // (3) (1) is fine, but I tend to add a cast anyway. (2) is undefined behavior due to shifting into the sign bit of a signed int, except with GCC it's well defined[*] but -fsanitize=undefined will still complain. (3) Even if the shift into the sign bit was OK, the conversion of a negative signed int to size_t is unlikely to produce the intended result. Maybe many people find the extra casts weird, but at least you know my rationale behind them now. [*] https://gcc.gnu.org/onlinedocs/gcc-16.1.0/gcc/Integers-implementation.html -- Lasse Collin