All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Richard Fitzgerald <rf@opensource.cirrus.com>,
	rostedt@goodmis.org, sergey.senozhatsky@gmail.com,
	linux@rasmusvillemoes.dk, shuah@kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	patches@opensource.cirrus.com
Subject: Re: [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf
Date: Thu, 4 Feb 2021 17:35:15 +0100	[thread overview]
Message-ID: <YBwiQ+l6yqs+g+rr@alley> (raw)
In-Reply-To: <YBr9c44Dvq1ZNrEa@smile.fi.intel.com>

On Wed 2021-02-03 21:45:55, Andy Shevchenko wrote:
> On Wed, Feb 03, 2021 at 04:50:07PM +0000, Richard Fitzgerald wrote:
> > The existing code attempted to handle numbers by doing a strto[u]l(),
> > ignoring the field width, and then repeatedly dividing to extract the
> > field out of the full converted value. If the string contains a run of
> > valid digits longer than will fit in a long or long long, this would
> > overflow and no amount of dividing can recover the correct value.

> ...
> 
> > +	for (; max_chars > 0; max_chars--) {
> 
> Less fragile is to write
> 
> 	while (max_chars--)

Except that the original was more obvious at least for me.
I always prefer more readable code when the compiler might do
the optimization easily. But this is my personal taste.
I am fine with both variants.

> 
> This allows max_char to be an unsigned type.
> 
> Moreover...
> 
> > +	return _parse_integer_limit(s, base, p, INT_MAX);
> 
> You have inconsistency with INT_MAX vs, size_t above.

Ah, this was on my request. INT_MAX is already used on many other
locations in vsnprintf() for this purpose.

An alternative is to fix all the other locations. We would need to
check if it is really safe. Well, I do not want to force Richard
to fix this historical mess. He already put a lot lot of effort
into fixing this long term issue.

...

> > -	unsigned long long result;
> > +	const char *cp;
> > +	unsigned long long result = 0ULL;
> >  	unsigned int rv;
> >  
> > -	cp = _parse_integer_fixup_radix(cp, &base);
> > -	rv = _parse_integer(cp, base, &result);
> 
> > +	if (max_chars == 0) {
> > +		cp = startp;
> > +		goto out;
> > +	}
> 
> It's redundant if I'm not mistaken.

Also this is more obvious and less error prone from my POV.
But I agree that it is redundant. I am not sure if this
function is used in some fast paths.

Again I am fine with both variants.

> > +	cp = _parse_integer_fixup_radix(startp, &base);
> > +	if ((cp - startp) >= max_chars) {
> > +		cp = startp + max_chars;
> > +		goto out;
> > +	}
> 
> This will be exactly the same, no?

Best Regards,
Petr

  reply	other threads:[~2021-02-04 16:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03 16:50 [PATCH v4 1/4] lib: vsprintf: scanf: Negative number must have field width > 1 Richard Fitzgerald
2021-02-03 16:50 ` [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf Richard Fitzgerald
2021-02-03 19:45   ` Andy Shevchenko
2021-02-04 16:35     ` Petr Mladek [this message]
2021-02-05 11:28       ` Richard Fitzgerald
2021-02-05 12:50         ` Andy Shevchenko
2021-02-05 15:23           ` David Laight
2021-02-05 15:53             ` Andy Shevchenko
2021-02-08 17:56           ` Petr Mladek
2021-02-08 11:47       ` Richard Fitzgerald
2021-02-03 16:50 ` [PATCH v4 3/4] lib: test_scanf: Add tests for sscanf number conversion Richard Fitzgerald
2021-02-03 19:47   ` Andy Shevchenko
2021-02-03 16:50 ` [PATCH v4 4/4] selftests: lib: Add wrapper script for test_scanf Richard Fitzgerald
2021-02-03 19:48   ` Andy Shevchenko
2021-02-03 19:48 ` [PATCH v4 1/4] lib: vsprintf: scanf: Negative number must have field width > 1 Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YBwiQ+l6yqs+g+rr@alley \
    --to=pmladek@suse.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=patches@opensource.cirrus.com \
    --cc=rf@opensource.cirrus.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.