All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] misc: suppress build warning
Date: Thu, 4 Dec 2014 23:37:54 -0800	[thread overview]
Message-ID: <20141204233754.286aa347.akpm@linux-foundation.org> (raw)
In-Reply-To: <20141204163032.GA29076@kroah.com>

On Thu, 4 Dec 2014 08:30:32 -0800 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Dec 04, 2014 at 03:13:00PM +0000, Prabhakar Lad wrote:
> > On Thu, Dec 4, 2014 at 2:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 04 December 2014 14:38:30 Lad, Prabhakar wrote:
> > >> this patch fixes following build warning:
> > >>
> > >> drivers/misc/ioc4.c: In function ___ioc4_probe___:
> > >> drivers/misc/ioc4.c:194:16: warning: ___start___ may be used uninitialized in this function [-Wmaybe-uninitialized]
> > >>   period = (end - start) /
> > >>                 ^
> > >> drivers/misc/ioc4.c:148:11: note: ___start___ was declared here
> > >>   uint64_t start, end, period;
> > >>
> > >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> > >
> > > Please explain why the compiler thinks there is a bug, why you
> > > are sure that there isn't, and why you picked '0' as the
> > > initialization value.
> > >
> > Its a false positive, to suppress the warning '0' was picked.
> 
> Are you _sure_ it's a false positive?  That odd do/while loop looks like
> it might just not ever initialize the start variable, are you sure the
> logic there is correct?
> 

As long as IOC4_CALIBRATE_END is greater than IOC4_CALIBRATE_DISCARD (it is),
`start' is written to.

It would be nice to simplify the code, but I'm not sure how.

And I really dislike this initialize-it-to-zero-to-stop-the-warning
thing which we do all over the place.  The reader doesn't know *why*
it's initialized to zero and the initialization can conceal bugs if we
get a code path which should have written to it but forgot to.  And it
adds unneeded code to vlinux.

I much prefer unintialized_var() which fixes the documentation issue
and doesn't add code.  But Linus and Ingo had a dummy-spit over it.

      reply	other threads:[~2014-12-05  7:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04 14:38 [PATCH] misc: suppress build warning Lad, Prabhakar
2014-12-04 14:59 ` Arnd Bergmann
2014-12-04 15:13   ` Prabhakar Lad
2014-12-04 16:30     ` Greg Kroah-Hartman
2014-12-05  7:37       ` Andrew Morton [this message]

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=20141204233754.286aa347.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prabhakar.csengg@gmail.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.