Re: [PATCH v6 1/5] lib: fix _parse_integer_limit() to handle overflow

[David Laight <david.laight.linux@gmail.com>]

On Thu, 12 Feb 2026 12:00:30 +0000
David Laight <david.laight.linux@gmail.com> wrote:

Re-send with "..." removed from one of the addresses so my MUA (claws) won't
escape the second one and the list-servers fail to accept the mail.

> On Thu, 12 Feb 2026 14:13:16 +0300
> Dmitry Antipov <dmantipov@yandex.ru> wrote:
> 
> > On Tue, 2026-02-10 at 09:36 +0200, Andy Shevchenko wrote:
> >   
> > > I don't see how max_chars is used. With that said, I would rather see the usual
> > > way of expressing the condition in the for-loop:
> > > 
> > > 	for (rv = 0; rv < max_chars; rv++, s++) {    
> > 
> > This will break the loop (and so stop consuming characters) if KSTRTOX_OVERFLOW
> > bit is set.
> >   
> > > > +		if (likely(res != ULLONG_MAX)) {    
> > > 
> > > Have you seen David's question about these checks?
> > > Maybe I missed your answer...  
> 
> I've not seen one...
> 
> > >     
> > > > +			if (unlikely(res & (~0ull << 60))) {    
> > 
> > The first check may be dropped indeed (assuming check_mul_overflow(ULLONG_MAX, a, b)
> > and check_add_overflow(ULLONG_MAX, a, b) always signals an overflow).  
> 
> That check for the high bits may well be cheaper than the one in
> check_mul_overflow() - which is likely to need to partially generate
> the 128bit result.
> Also if the code is going to call check_mul_overflow() it ought to use the
> result in the 'non-overflow' case.
> 
> But there is nothing 'magic' about check_mul_overflow(), given the base
> is known (and the only dificult one is 10) comparing against the known
> limit will be better code.
> 
> 	David
> 
> 
> > 
> > Dmitry  
>