Re: [PATCH v6 2/5] lib: fix memparse() to handle overflow

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Mon, Feb 09, 2026 at 07:47:54PM +0300, Dmitry Antipov wrote:
> Since '_parse_integer_limit()' (and so 'simple_strtoull()') is now
> capable to handle overflow, adjust 'memparse()' to handle overflow
> (denoted by ULLONG_MAX) returned from 'simple_strtoull()'. Also
> use 'check_shl_overflow()' to catch an overflow possibly caused
> by processing size suffix and denote it with ULLONG_MAX as well.

...

>  unsigned long long memparse(const char *ptr, char **retptr)
>  {
>  	char *endptr;	/* local pointer to end of parsed string */
> -
>  	unsigned long long ret = simple_strtoull(ptr, &endptr, 0);
> +	unsigned int shl = 0;
>  
> +	/* Consume valid suffix even in case of overflow. */
>  	switch (*endptr) {
>  	case 'E':
>  	case 'e':
> -		ret <<= 10;
> +		shl += 10;
>  		fallthrough;
>  	case 'P':
>  	case 'p':
> -		ret <<= 10;
> +		shl += 10;
>  		fallthrough;
>  	case 'T':
>  	case 't':
> -		ret <<= 10;
> +		shl += 10;
>  		fallthrough;
>  	case 'G':
>  	case 'g':
> -		ret <<= 10;
> +		shl += 10;
>  		fallthrough;
>  	case 'M':
>  	case 'm':
> -		ret <<= 10;
> +		shl += 10;
>  		fallthrough;
>  	case 'K':
>  	case 'k':
> -		ret <<= 10;
> +		shl += 10;
>  		endptr++;
>  		fallthrough;
>  	default:
>  		break;
>  	}

> +	if (shl) {
> +		/* Valid suffix without preceding number. */
> +		if (unlikely(ptr == endptr - 1)) {

I believe this can be optimised with the endptr++ moved somewhere here.
I have not yet a clear picture in my mind, just gut feelings, so please
try to think about it. With that we won't need endptr--.

> +			endptr--;

> +			ret = 0;

Wouldn't ret be already 0 here?

> +		}
> +		/* Apply suffix if no overflow. */
> +		else if (likely(ret != ULLONG_MAX)) {

Should be (style)

		/* Apply suffix if no overflow. */
		} else if (likely(ret != ULLONG_MAX)) {

> +			unsigned long long val;
> +
> +			if (unlikely(check_shl_overflow(ret, shl, &val)))
> +				ret = ULLONG_MAX;
> +			else
> +				ret = val;
> +		}
> +	}

Strictly speaking this is an ABI breakage. I dunno how many (broken) strings
will stop working after this check.

-- 
With Best Regards,
Andy Shevchenko