lkml.org 
[lkml]   [2021]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v4 2/4] lib: vsprintf: Fix handling of number field widths in vsscanf
On Fri, Feb 5, 2021 at 5:23 PM David Laight <David.Laight@aculab.com> wrote:
> From: Andy Shevchenko
> > Sent: 05 February 2021 12:51
> > On Fri, Feb 5, 2021 at 1:35 PM Richard Fitzgerald
> > <rf@opensource.cirrus.com> wrote:
> > > On 04/02/2021 16:35, Petr Mladek wrote:
> > > > On Wed 2021-02-03 21:45:55, Andy Shevchenko wrote:
> > > >> On Wed, Feb 03, 2021 at 04:50:07PM +0000, Richard Fitzgerald wrote:
> >
> > ...
> >
> > > >>> + 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.
> >
> > I *slightly* prefer while-loop *in this case* due to less characters
> > to parse to understand the logic.
>
> The two loops are also have different values for 'max_chars'
> inside the loop body.

off-by-one to be precise.

> If 'max_chars' is known to be non-zero the do ... while (--max_chars);
> loop will probable generate better code.

What?! while (--x) and while(x--) are equivalent.

> But there is no accounting for just how odd some decisions gcc
> makes are.

Why should we care about the compiler bugs here?

--
With Best Regards,
Andy Shevchenko

\
 
 \ /
  Last update: 2021-02-06 00:53    [W:0.083 / U:4.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site