From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 68D513CC7EC for ; Tue, 12 May 2026 16:18:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778602700; cv=none; b=U7wtCs/NjwFqLAB8kve00JdMIqn8EWOfp3qjDQbTYm7kXPPL1By3E3f3xI9hEAWKNlSUkW9SP3gw3rEYHQgaV7r9DBUskjD+sez6fj6a9TrWer33zZmuCI5ppV+lyC3cy3Vk+hnZAmVDgI+fB9siiEYNsig7LtvQBS+NLrMvoOY= 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.41 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-f41.google.com with SMTP id ffacd0b85a97d-43d7e23defbso3414228f8f.0 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=NIYmytTgEn8pj74VtIzCkR1mOISKiiSll4WNgHxS4oijun9mOnu8iZ1RFjl4wFusEi 8Z1Rp8wtpUG+2HYfw4FGz5wheoGu1PN675Q630DnpcpCWPd6mgU0UEmUYIyuW5k7VD/Y sM7t+WhcPvxRbqPmPD3+dPzcdOLSu4yLuEDT4OGocsX5egMlhDReoJ75AfGCj2q2zEBE IYj917Hi8xUH8iKsta3ai0Cg+xQIchaZKKyP3uIN0fK+RzVEC6rykCigJysmtH4y93WO gCH+RFdXzH2upA6Ff15Xar+8bUom+qLRs34leWJjs5NM6s9UusnEHgHmgqQLaziMCGxg cjjA== X-Forwarded-Encrypted: i=1; AFNElJ80Da0s1FJWgryK0GUNX5QjTfZy8boyPsuXnRxewAGRPsoDUTsOBu1htXpAFQNpxZjQatn594Z+KroV@vger.kernel.org X-Gm-Message-State: AOJu0YwnHSTYukkc3KLQz172HxI7pGCtKzP95JIxZkJ2PlqYhDrQ/3wf TEX+2roghgpzZnhtRNxTNHFy1FISapsuVru1PgU7tmDmaHuvq1s1rfwj X-Gm-Gg: Acq92OHGDKYjD/sJq+hPiX0PFPSiIhHpwz1Yhd0MPQhhp7PHpETZZVcVP1Ta0Qz4tSP j+cLjGOHshEDWy1aDeqStCPRGDrw6b0ZzazCZNLl2CWSBbM8i80Jh/2cqOXHDCLvZvFNrl2hU4E J7lPzrcml+jJYRpRdAdDNRhCUHKibTQVEFjf4SHXK3O+H7TGmxS/1EiTt44vsnMmpe1Y82K7Q7g //lH690YLQ/zj6WMu96gIvkfyDsAGa1uELYwC//kteuUtxwQeNZ7ssjijsQxXrzo7b72vJ25J+i 6bIyKg+9mMpDCd5RKt8a1nd+pTtg3m3rHUj62ryu0ByqtIdt2V36XTCJvIkrvSMon0fZ5NAHGwZ jtzAgIGtajJxRAKXmYme+UHUmrJ+pFNi+cn3ddMt49jk2Kbd9e9/jweHkESECZBTZ8DdHUcXm9K J8BjY75cC+DYpYcchOrfA9nn8MkgBjPVtpdzgbPKoohdpSlBg8qXWsS76zqKtF 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: devicetree@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. > > >