From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 D40732528FD; Tue, 27 Jan 2026 22:08:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769551728; cv=none; b=R/JR2A90nl+x5PfMvmbt6o3TDxUnZLdAu7On6f+VhKDamalLinhr7++XEZrMNQLuq18GSmrwSZfLCu0xSiFoyNJar1DhUhPRVU+ZII7/wtHPBTdqJfjQdg2f6CKUBDNsXJsk3GWs/I4OonNiQszNSZaUClTyBtOQLL6du8zy7Nc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769551728; c=relaxed/simple; bh=zNVhpK/eZkgjDcqYKfDXwfMPXICvW52/vsM2Le5DWTY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=abPv/yNpDWsIBrpVzZkLkbt/AfJABKjCKpi4uwpAsui9QpRbrv0EAtwp/0IRww5em2LPz5kuVjOUmLC4Hv3szX+AkGvoBQy3McZRiwTcOKFcYNX3AIcxoAhY8w/y/9CjLctpjr9F+5iwsXRGrr2DUappzEJCY0cv7l0OGWhzJHo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=L/jbmUyY; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="L/jbmUyY" Received: from [172.27.2.41] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 60RM8DIF3885489 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Jan 2026 14:08:17 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 60RM8DIF3885489 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1769551703; bh=y6oQ+uU7Q3nNg8DhxvmUv17AhGXlIrzJZrr4lvC2aak=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=L/jbmUyY8rTYcmXtCACsourh+UsnYa5sLFXMiTh5vsW9LvP623NbcECoo6P0I4XAr F2x8JjtqADk1Jr4uOgcRal76ZYdDU0Atr9lDOxpqXSSr5kteGRve8JranIWKWRbK5L nAjr3Ugfdt5CvzlVK+ptm1y/PfzGjQJF8IjfLJ81MfNIQfHTAneFxeIdqRhySihZbN 979g0YiEJqdgdnC8kBHvNN3D2T8skbw8AaS9/HCghG5+bHEMJVF8+qjE1t4SS/6Nrg i4lc4luY+87ZydMSy5rk/ThKHc5oDi04N7r7w6N5H6wjWZysF/+LB2mBkBEALO0Gy7 OALr36iXO0eZg== Message-ID: <93b5c10e-747d-4164-9733-947a63b4f25d@zytor.com> Date: Tue, 27 Jan 2026 14:08:07 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach To: Andy Shevchenko , David Disseldorp Cc: Christian Brauner , Petr Mladek , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Al Viro , Jan Kara , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , Andrew Morton References: <20260119204151.1447503-1-andriy.shevchenko@linux.intel.com> <20260119204151.1447503-3-andriy.shevchenko@linux.intel.com> <20260120230030.5813bfb1.ddiss@suse.de> <20260121080015.6aca8808.ddiss@suse.de> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-01-20 13:17, Andy Shevchenko wrote: >> >> I.e. a "0x" isn't specified as valid prefix. I don't feel strongly >> regarding diverging from existing behaviour, > >> but it should still be >> considered (and documented) as a potentially user-visible regression. > > I disagree, this is not specified and should not be used. The CPIO archive in > the original form doesn't specify leading 0 for octals (at least how I read it, > please correct me, if I'm wrong). > > https://pubs.opengroup.org/onlinepubs/007908799/xcu/pax.html > This is the "newc" or "crc" format used by BSD (header magic 070701 and 070702, respectively), those were never standardized by POSIX. These formats use 8-character hexadecimal (%08x). As far as a 0x prefix, or upper case -- no, that is technically not according to spec, but we DO NOT break user space tools that have been working for 20+ years, unless it is either (a) a security problem or (b) is holding back further development (e.g. because the format is ambiguous. This is Postel's law in action. -hpa