All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Alexander Sverdlin <alexander.sverdlin@gmail.com>,
	Johan Hovold <johan@kernel.org>,
	linux-serial@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] serial: 8250_omap: fix a timeout loop condition
Date: Fri, 30 Apr 2021 17:21:24 +0300	[thread overview]
Message-ID: <YIwSZGE76f2ZJyyf@smile.fi.intel.com> (raw)
In-Reply-To: <20210430133329.GH1981@kadam>

On Fri, Apr 30, 2021 at 04:33:29PM +0300, Dan Carpenter wrote:
> On Fri, Apr 30, 2021 at 03:53:44PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 30, 2021 at 02:41:06PM +0300, Dan Carpenter wrote:
> > > On Fri, Apr 30, 2021 at 11:46:07AM +0300, Andy Shevchenko wrote:

...

> > > Why would I make it unsigned?  As a static analysis developer,
> > > pointlessly unsigned variables are one of the leading causes for the
> > > bugs I see.
> > > 
> > > There are times where a iterator counter needs to be unsigned long, or
> > > u64 but I have never seen a case where changing an iterator from
> > > "int i;" to "unsigned int i;" solves a real life kernel bug.  It only
> > > introduces bugs.
> > 
> > See my followup to that, I meant
> > 
> > unsigned int count;
> > 
> > do {
> > 	...
> > } while (--count);
> > 
> > It doesn't solve bug, but prevents the code be read incorrectly like what you
> > are fixing can be avoided with do {} while (); along with unsigned type.
> 
> Why would you use an unsigned int for this???

Why it should be signed? You clearly show the amount of iterations. Check for
null I guess even compact in the assembly in comparison to -1.

I do not see any point why it should be signed. For what purpose?

It's a *down* counter.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-04-30 14:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29  7:19 [PATCH] serial: 8250_omap: fix a timeout loop condition Dan Carpenter
2021-04-29  9:23 ` Alexander Sverdlin
2021-04-29 11:08 ` Andy Shevchenko
2021-04-29 13:02   ` Dan Carpenter
2021-04-30  8:46     ` Andy Shevchenko
2021-04-30  8:47       ` Andy Shevchenko
2021-04-30 11:41       ` Dan Carpenter
2021-04-30 12:53         ` Andy Shevchenko
2021-04-30 13:33           ` Dan Carpenter
2021-04-30 14:21             ` Andy Shevchenko [this message]
2021-05-03  6:54               ` Dan Carpenter
2021-05-03  9:51                 ` Andy Shevchenko
2021-05-14  8:00                   ` Dan Carpenter

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=YIwSZGE76f2ZJyyf@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=alexander.sverdlin@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=vigneshr@ti.com \
    /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.