From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68C6D383327 for ; Tue, 12 May 2026 16:18:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778602700; cv=none; b=u8/yS4OIVMwJJNwtytiZiEOBGCYZ7kpaZ5cACeVr6cGMkT5xbb4c5jX8h/QZS0YmMroyHB7HXwzRRf9uRzMXh71XAR2IhbLjGOxpVtSM9CBJKaN6P5oTHpVNkEYYJQsdK0gUlg6VP+WwQ1qMvprLZwh521BpI1MKAxuxXt4Xo5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778602700; c=relaxed/simple; bh=AtvxZEfNK52qh8Sntbt6SqFzqSBGmvWLF/8w119Z9Us=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mDEimW6Pr4IrW93EmjVD1FA50zbmUExPjoREdJYnZ+ujEL2LLiUX4IKkMqr8imT/w7YuGEQmih3t66+olsJ3kjXNbatqK3Kv+yI+z7pO8EqOLq0NfYjZUbqaC+EMeok1JYffNNtV9gUM/t/TFTsCUu69QvZU+xu8+AWu26EL+/M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DRYzF1sF; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DRYzF1sF" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-4526a8170ceso3176911f8f.2 for ; Tue, 12 May 2026 09:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778602697; x=1779207497; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=LLDhRrsYYAieX5MKmnLKzaUv/WL8O+rmn/hVKUTlz+0=; b=DRYzF1sFFkDifTiZl8MxVfreVi3OJ9c8ENougW5kmP1lmpZJ3qCAySvVWMyzWMgq0V tupJ1ysCcidUX6DHiPfHukN+Poukp8+qX7f9clPGEyJB6lFqHbdnQt0aWcL6Y0hBfdzR YjTh91NhBWF5BddPhz5piv22gpUfmvgpmpZFV766NVNo+mD6HVwHz8g9b82jolZxlrMW xjou541h6eiBvrziplYmhOUNPlN9M+7sqm/VB5yl5S04LN3s+LlnH8wqhJ5WLMuO/cdN t1gC/v85D2jfJ1+KGzVZcW6p9JYQpYwK2VhLg6UWMebPUsVJXlAjpD7Kfxp0uTQp0N2J /zEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778602697; x=1779207497; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=LLDhRrsYYAieX5MKmnLKzaUv/WL8O+rmn/hVKUTlz+0=; b=Q4q9Htt0IRLjfYO5W6620PAnpYxlB8B0wT0jEJ0AHCmbT7g2NVBfN79GmDv+8iuj6+ pAiIBIB+JslHtfAC1DhOicp1Bek9KYTFDbMsW/q/d+T4gjozrZD+f3MEkVYHyetstELm urphDaHoH2/bVxS69W1vTKly9/cpeQHdCcROlh/t4tFpl0tzzBJ6Ox+0elsVWspGhh0/ 8m7ET8zNwmGNd+uC1l/FKZsGj12odK/eolc1G2xZQ5J8gFO8Kk6NwElTU7TkMtFvHusg G+sLUGnIU4lAtOChn/D8T9DAVkPH/n6g7vpMgZ08BISPCHXOdWV+ej0PwQUkG2u4PALI kwYg== X-Forwarded-Encrypted: i=1; AFNElJ+8eHOcJq11CeoXlaPCZOxIxhI6nHaBMiORm7JsygjLNfqRUNIwyy1R0yMIV36Z+ZE4i9sB7fDKWVJyvmI=@vger.kernel.org X-Gm-Message-State: AOJu0Ywng612D5jB9F6e+WwonTnCIy1TeUS2FzDPTTMLhOUZMVJol/GB 8HMBuHwbM0UDYk+9Aog0cUu4eqf2Hmyf2L9Kl8/SJjKXAGdFv1COG5RX X-Gm-Gg: Acq92OEL5Tbx1gVRldtVl+F3dUpNbADLdff3Bhk5GL7brblajfJhJTWwGagkqmt883K bDVuBoIyQohILMyabUHncLF9PUhei2lDW7Qf9DgKw+v1T7+uh3d7mA3EX85Vc6i3K38wELCkV39 hVb6yRrZEDhzZZdO84Bre3TL3h7819/CcBSfvoE5KfTntLpbjjRDSpRE7RXku+wLFEBaFY95OsP RIip/GBgrt4eT6UFWirz/5Nho39gPypnQwYh6CxH7tmVWdQ2gRfxo6KITlgYPcR/eNEDGMyZDz8 zxU3kN3LItb1BYeiTiJ//thdPe3VeQNgnFxTjTqZVkkahiopI3cMDFKg2P8SX0MRSKzgVwqEyas N4X3jR74mlVxvpEZgcS4bTQKUzmAR3tRFisKoxa2vAm2//d0aWkA6zkpyhYAYxRdKR7vL63atCO bkGGeT7Yn1qe5olcVN5bbW6Ec3hHnw/jsFBnP2+tBvri6E8zefaU/ePmJc46hZ X-Received: by 2002:adf:e9d2:0:b0:456:b23d:e57 with SMTP id ffacd0b85a97d-456b23d0edcmr16115850f8f.0.1778602696592; Tue, 12 May 2026 09:18:16 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548ec6b071sm33302475f8f.14.2026.05.12.09.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 09:18:16 -0700 (PDT) Date: Tue, 12 May 2026 17:18:14 +0100 From: David Laight To: Andy Shevchenko Cc: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>, Andy Shevchenko , Jonathan Cameron , Rodrigo Alencar via B4 Relay , rodrigo.alencar@analog.com, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, David Lechner , Andy Shevchenko , Lars-Peter Clausen , Michael Hennerich , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonathan Corbet , Andrew Morton , Petr Mladek , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , Shuah Khan Subject: Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64() Message-ID: <20260512171814.1934aeb4@pumpkin> In-Reply-To: References: <20260510-adf41513-iio-driver-v12-0-34af2ed2779f@analog.com> <20260510-adf41513-iio-driver-v12-2-34af2ed2779f@analog.com> <20260512123953.40d80bc9@jic23-huawei> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Tue, 12 May 2026 18:21:44 +0300 Andy Shevchenko wrote: ... > > I think we are going in circles here and we could look at the code instead: > > - integer parsing with _parse_integer() > > - overflow check and validation of the return value > > - fractional parsing with _parse_integer_limit() > > - overflow check and validation of the return value > > No, this is not fully true. That's what my whole point is about. The > max_chars parameter limits the input check, then it skips an arbitrary > number of digits and only *then* it checks for \n and \0. What will be > the result of the > 0.00000000000000000000000000000000423 in your case? Whatever scale you > gave it will return 0 without checking on how many digits were > supplied. All the same for 0.9999999999999999999999999999999000423. My > point is that we should limit this by 19 digits. Don't forget about 000000000.123 And that you also need to worry about leading spaces affecting the length. To me, the easy way to parse it is to know how many digits are valid after the '.' and just carry on parsing digits after a '.' until the limit is hit. If you really want one function, pass zero to indicate that '.' is invalid. > > On top of that, what about -0.9(19 times) ? the fraction should be u64 > in this case and it's fine. The sign applies to the combined value. > > > - extra scaling and truncation happening outside if needed. > > Right, but the given input may be way too long and still needs more validation. > > > - check for input termination > > - combination of integer and fractional parts with check_mul_overflow() and check_add_overflow() A lot of the time overflow can be ignored because the digit string is short. The check_mul_overflow() code is likely to measurably slow things down. (Especially on 32bit where even a compare against 2**64/10 isn't cheap.) -- David > > > > > > > Maybe I'm missing these checks already performed? > > > > > > > > > > > > Having the test cases is a big benefit, and that part I like the most. > > >